Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: /Library/Extensions folder supported?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /Library/Extensions folder supported?

On Monday, December 9, 2002, at 10:37 AM, Kevin Van Vechten wrote:
At 09:50 -0800 on 12/9/02, Dean Reece wrote:
On Sunday, December 8, 2002, at 12:08 PM, Kevin Elliott wrote:
I recently installed the new version of PGP and noticed that it installs a kext into /Library/Extensions (after creating the directory).

I've heard this complaint before, but I still don't understand the reason. Even if we did look for KEXTs in /Library/Extensions, the ownership rules would be the same as /S/L/E, so its not like it would simplify installers at all.

Because the current situation breaks the implied logic of the system. Implicitly the logic is "System wide stuff apple needs is in System", "System wide stuff used by 3rd parties is in /Library", and "non system wide stuff is in your home directory". As things stand today if I want to know what third party kext are installed I first have to know enough about the system to know what kext's apple installs. I'm a little surprised you've never heard this argument. I clearly remember this issue being raised and discussed at the very first IOKit kitchens.

Yes, I've heard this before, and I don't disagree with the principle. The fact remains that since this isn't supported now, even if we added it for the next release, you'd have to look in both places (at least for a few years until all developers switched over).

The reasons we don't support /L/E now are not really technical showstoppers, but adding another place for both BootX and the kext tools to look, plus managing two separate caches, adds some complexity with little real (end-user) benefit. It also adds some (small) risk to the bootability of the system, since the more paths the booter has to traverse, the more chances that a corrupt root filesystem will be unbootable. This was discussed during the design of the kext system, and we decided that both the risk and the benefit were small, so we decided on the simpler solution (one location).

I definitely agree with Kevin's argument in that /Library is for 3rd party, site-specific, but site-wide installations. This is the philosophy used by SystemStarter, both /System/Library/StartupItems, and /Library/StartupItems are searched at startup. (in fact when conflicts are encountered, /Library/ wins).

I don't disagree with the philosophy, and I'm not saying that Apple will never support /Library/Extensions in some form.

Keep in mind that every bit of engineering we do means that some other bit of engineering isn't getting done (we have more work to do than people to do it). This may seem like a trivial change, but consider the following would need to change: BootX, the kernel, kextcache, kextd, possibly the startup scripts, various man pages and other documentation. DTS would need to draft a technote on this and have it reviewed and posted. We would have to introduce new test scenarios to cover this, etc. I just don't see this as an enabling feature. As an engineering manager, it is my duty to address more critical requirements first, and this just isn't high on the list. I am not trying to be flip; I'm just trying to explain why it sometimes seems that we never get around to such "obvious" improvements.

Also, I think this made the safe-boot stuff fairly simple, we just ignore /Library/StartupItems during safe-boot.

That will not work for kexts. Just because an extension is from a 3rd party doesn't mean it isn't needed for safe-boot (Adaptec drivers?, special mouse drivers?). Likewise, just because an extension is from Apple, doesn't mean that it is needed for booting. We use the "OSBundleRequired" key to control what kexts are loaded during safe-boot, and in fact this gives us some finer grained controls so that we load just the kexts needed for the particular type of boot taking place.

Further, we are reserving /Library/Extensions for future use, so PGP is definitely at risk of not being forward-compatible.
Huh? Out of curiosity, where was that documented?

OK, I think I spoke a bit too strongly. The definitive documentation on /L/E is at: FileSystem/_The_Library_Directory.html

It indicates that 3rd party apps are free to create subdirs in /L/E. It also say the "Extensions" dir is only in the System domain; from this I infer that this dir should not be created in other domains. My memory was that standard subdir names were considered reserved, but the document doesn't reflect this. As a developer myself, I'd steer clear of any such names, since the risk of collision is certainly high.

If a future version of Mac OS X starts scanning /L/E and auto-loading kexts using the same rules as /S/L/E, we may find and load the PGP (or other similarly located) kexts automatically, and those kexts are likely expecting to be loaded by their helper daemon/utility. This may effect their load order and/or timing; I've witnessed first hand the carnage that can come from such changes (panic on every boot in extreme cases). This is what I mean by "at risk of not being forward-compatible".

Please steer clear of /Library/Extensions (and ~/Library/Extensions) until such time as Apple provides support for it and offers guidance on it's proper use.

Are kext that load during booting supported?
Yes, I/O Kit does this all the time. KEXTs can also be loaded using kextload from a StartupItem.
LOL. Not exactly what I meant... I was talking about kext in /Library/Extensions being probed during booting, which is clearly not the case based on the above.
My vote is to have /Library/Extensions searched at boot in addition to /System/Library/Extensions, both with the same strict permission requirements.

Understood, and we may in fact do this for some future release, but for now please stay clear of /Library/Extensions (and ~/Library/Extensions).

- Dean
darwin-development mailing list | email@hidden
Do not post admin requests to the list. They will be ignored.

 >Re: /Library/Extensions folder supported? (From: Kevin Van Vechten <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.