Re: Using OSKextRequestResouce from kext init routine?
Re: Using OSKextRequestResouce from kext init routine?
- Subject: Re: Using OSKextRequestResouce from kext init routine?
- From: Ken Hornstein <email@hidden>
- Date: Sun, 16 May 2010 16:21:15 -0400
>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.
You're presuming that I'm not doing that already, and you'd be
wrong; these kexts already write directly to files. And the fact
that Apple already provides a supported series of kpi's to do exactly
that really makes me think that Apple realized that it can occasionally
be useful. I can tell you from direct experience that it's not
difficult to do it right: it's actually pretty straightforward, and
I have not run into any problems. I will agree that it's not ideal,
but the alternative would involve writing a lot of new code that I
am, quite frankly, not that interested in writing.
> - Have all of the 15 kexts start routines just check in with a
>'manager' of some sort, and have the 'manager' handle fetching your
>properties and sequencing the 'real' startup routines correctly.
>
> - Link all 15 kexts together into one mondo kext. Have a 'true' start
>routine that handles property fetches and sequencing of the
>initialisation of the other kexts.
Yeah ... I'm not going to do either of those things. Why? Well,
it's a lot of new code I would have to write. The only gain I can
see to writing all of this new could would be that I would avoid
having to write to and from files directly from my kext. Since I
already know how to do that, just reading in the module options
seems like the simplest option. I agree that it's not ideal, but
sometimes thats just the way it works out.
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden