site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com There should be headerdoc for the function, but I just tried to search for in Xcode and got zilch. The comments are in the header, though. As for your problem, OSKextRequestResource() is asynchronous (as any up-call from the kernel pretty much has to be). All it does is queue a request for kextd to fulfill. However, kext start & stop routines are synchrounous with regard to kext load and unload, so if your kext is being loaded by kextd, kextd won't even see the resource request until your kext has returned from its start routine. It's perfectly fine to call OSKextRequestResource() from your kext start routine, but as you noted, you cannot expect the request to be fulfilled within the scope of that call, so you can't base success/failure of the start routine on the availability of a resource (which I am guessing is what you want to do). You can log an error from the resource callback, and even arrange for your kext to be autounloaded, but you cannot cause the load itself to fail on an unavailable resource. Even if we modified kextd to be all multithreaded and able to take simultaneous requests from the kernel, we couldn't guarantee execution time on any requests received. (More-than-you-probably-care-to-know alert.) This feature was designed to handle the issue of drivers with huge firmware blobs in their personalities, which consume kernel wired memory whether the drivers are loaded or not (and worse, get copied for each instance of the driver class created if they do get loaded). A fully general, synchronous-capable solution that worked during early boot (before kextd) as well as later would have been prohibitively expensive, requiring kexts to name which resource files might be needed during a load, the booter to look for those resources and copy them into memory, mkext & kernelcache to be built including those resource, the kernel to find them and catalog them in case a kext should need one, and kext load operations to also grab them and send them down as part of the load operation. The code that would be involved and regressions in boot time and (albeit temporary) wired memory made that simply infeasible. (Whew!) If you have a BSD kext that requirest a single moderately-sized resource to start, it isn't so bad to just include the data in your executable. Nik Gervae The Guy Who Wrote That On 14 May, 2010, at 11:48 , Ken Hornstein wrote:

I'm having an issue with using /(), specifically from my kext initialization routine.

This function is unfortunately not well documented (hey, if there's documentation for it, point me to it!), but ... it seems like you can't use it from a kext initialization routine. More specifically, you can't expect the callback to be called until after your initialization routine exits (actually, it's worse than that, from what I can tell; I have a bunch of kexts that depend on each other, and none of the callbacks are called until after they all finish loading and are started). Is my understanding correct? (I would guess that's more of a limitation in kextd).

--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/ngervae%40apple.com

This email sent to ngervae@apple.com

_______________________________________________ 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