Apple

On May 15, 2010, at 4:09 PM, Ken Hornstein wrote:

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.

From what you've described so far, you're not really all that far off the rails.

The general reason for not doing file I/O from inside the kernel is that it's just not designed to work that way. File I/O is something that user processes do, or more specifically that parts of the kernel do on behalf of user processes. Trying to do it from other parts of the kernel can lead to surprising (the bad kind) results. It's quite difficult to do right, and there is almost always a better way that moves the file I/O into userspace.

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.

That's the general idea; every property in that part of the plist ends up in the IORegistryEntry that your node inherits from.

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.

References:
	>Re: Using OSKextRequestResouce from kext init routine? (From: Ken Hornstein <email@hidden>)