Re: Deploying kext
Re: Deploying kext
- Subject: Re: Deploying kext
- From: Rustam Muginov <email@hidden>
- Date: Fri, 28 Sep 2007 10:29:39 +0400
Thank you for your answers, Dean.
So if my software package already does have /Library/Application Support/MySoftware folder, is it the right place to put kext into and not to pollute /S/L/E folder?
Also, where can i find the recommended example of launchd plist file to load kext at system boot time?
-- Sincerely, Rustam Muginov
On 28.09.2007, at 0:08, Dean Reece wrote: On Sep 27, 2007, at 1:16 AM, Rustam Muginov wrote: I am developing package to install software containing kext and run into some questions. The kext itself is a Kauthorama-like file access intercepter, and it is not bound to any IOKit devices.
1) As far as I found, kernel would not load non-IOKit kext automatically. I have to use launchd to make my kext load right after the system booted. Am I right?
Yes, this is the supported approach. Where is such behaviour documented?
2) I made a short launchd file to load the kext <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>Label</key> <string>com.mycompany.mykext_loader</string> <key>ProgramArguments</key> <array> <string>kextload</string> <string>/System/Library/Extensions/mykext.kext</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
It works ok, but how can i made this "pseudo-daemon" not to be shown in the "sudo launchctl list" output?
3) If my kext would not auto-loaded anyway, are where any reason to put in into /System/Library/Extensions folder? May be where would be more appropriate, somewhere inside the /Library folder?
In general, I'd recommend keeping it within (or close to) related software - such as a the Resources forlder within the bundle of the app that uses it. If it is a standalone kext without an obvious other place to be, /S/L/E is probably the right place to install it.
Please don't create the path /Library/Extensions and install it there. I don't want to restart the thread on why we don't already support that (check the archives if you are interested), but having 3rd party kexts install there will be a bad thing: If we choose to support that path in the future, the semantics we choose for kexts located there may not be compatible with what you or other 3rd parties expect and so it may create future product compatibility problems.
Thanks, - Dean
|
_______________________________________________
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