site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com
It occurs to me, though, that maybe I'm making this harder than I need to. I mean, I could simply call the appropriate vnode routines to read in the file and parse it myself. In a perfect world I could parse a prefs XML file from the kernel (or have it parsed for me by a userspace daemon), but somehow I don't see that happening anytime soon :-/
That's very bad, don't do that. How big are your preferences? Can you make an I/O Kit kext for your filesystem (match on IOBSD) and get your prefs via the kext's info.plist?
Um, why is that bad, actually? All of the routines to read a file from a kext are exported, supported routines (vnode_open() and vn_rdwr() are part of the BSD kpi). I suppose there might be some architectural purity reasons why I shouldn't, but honestly ... I'm already so far off of the reservation here, architectural purity is the least of my concerns. I have no objection to making an I/O Kit kext, but it's not clear to me how exactly I do that (nor is it clear to me how doing that means I get access to the kext's Info.plist). Unless .... are you talking about putting the stuff under IOKitPersonalities. Phew ... that seems like a lot of code. (I haven't really looked at I/O Kit very much, since it's all focused on hardware). Unfortunately, the documentation about I/O Kit seems large, and unless there's a good example I don't think I have the energy to look through it all, understand it, and make a lot of changes when it's for a relatively small section of code that I need.
Is there any reason you can't defer your registration, so use OSKextRequestResource but use the completion context rather than the context that called your start routine to complete your startup?
I actually tried doing that ... but it's complicated. The main issue here is kext ordering. Right or wrong, the filesystem doesn't consist of one kext ... there are actually 15. I can't take the blame for that one; that's just how it is organized. Certain kext's need to load _and start_ before others. Right now that's handled by the dependencies in the kext's Info.plist. But when I tried running the kext initializations from the OSKextRequestResource callback, I started getting kernel panics, and I traced those down to the kext's trying to use uninitialized resources. I suppose I could do some dependency tracking myself ... but that seems like a lot of work, again, for relatively little gain. --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com