On Oct 5, 2007, at 12:06 PM, JanakiRam wrote: I've my application which has kext and user daemon. Presently i'm using System Startup item to load kext and launch user process/daemon.
I've specified the OSBundleRequired property value as Root and disabled the startup item to load kext. I've restarted my machine and opened terminal and grepped for my kext from kextstat. Its evident that my kext is not loaded.
Right, what you are encountering is a common problem - we need to make the documentation more clear on this subject.
The OSBundleRequired property does not actually cause your kext to be loaded (as you discovered). What it tells the OS is that this kext may be asked for in order to mount the root volume. This is important because kexts generally live on the root volume, and so this property ensures the kext is included in the appropriate boot-time caches. The subtle difference here that "available for loading" is not the same as "loaded".
The design of the kext manager is such that no kext in Mac OS X loads unless something has asked for it to load. This demand-based load mechanism is important to prevent bloat. Otherwise, loading all the kexts that had this property every time would chew up a lot of kernel memory, and as a system aged and collected drivers for hardware long disused, the problem would get worse. Remember, lots of our customers to upgrade installs, and could have kexts hanging around for many years.
IOKit kexts are generally requested by the kernel as a result of hardware being discovered. BSD kexts are requested by name by a user-land agent (helper utility, daemon, startup item, etc). Currently, the BSD part of the kernel never requests a kext to be loaded, so there is no mechanism to accomplish what you want without becoming an IOKit kext.
So, this begs the question: why do you need to load this early if your code is not necessary for booting? I'm guessing you want to hook something prior to root mounting or some other service starting up, but if you can provide more details about what you want to accomplish, we may be able to offer a better solution.
Cheers, - Dean |