site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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... At 12:13 +0530 7/12/07, JanakiRam wrote: I've developed a kext for my product . To have more control on loading the kext (after login) , i'm planning to place it at custom location ( /opt/myproductfolder) instead of /System/Library/Extensions. The only reason you /need/ to be in "/System/Library/Extensions" is if you want the KEXT to be loaded automatically via the I/O Kit matching process. If that's not necessary, as seems to be the case here, there's no requirement to be in "/System/Library/Extensions". As to whether you /should/ be in "/System/Library/Extensions" it kinda depends on the context of your product. For example, if you were a VFS plug-in developer, I would recommend that you embed your KEXT within your file system bundle. That way there's would be a single file system object that represents your product. And, given that file system bundles are installed in a secure location ("/Library/Filesystems" on 10.5 and later, or "/System/Library/Filesystems" on earlier systems), there's now downside to putting a KEXT there. In your case, you want to load your KEXT post login. Loading the KEXT is a privileged operation, so the code that does the loading must be in a secure location. Thus, in the absence of further information, I'd recommend that put the KEXT within the bundle containing that code. I'd recommend you avoid "/opt" unless your product will only be used by UNIX geeks. Even amongst UNIX geeks, some fraction of the population hates "/opt" (-: If you need a secure location for your KEXT (and the code that loads it), I recommend that you create a root:wheel rwxr-xr-x directory within "/Library". To minimise the chance of collision, the name of the directory should be either your company or product name. Oh, yeah, /don't/ use "/Library/Application Support". That folder is not appropriate for privileged code. This email sent to site_archiver@lists.apple.com