[Big Mac]

I was looking through the System Profiler kext listing on my G5 and thought of two questions that bothered me:

1. I really have to wonder about Apple's choice to intermingle 1st and third party kexts. Wouldn't it have made more sense for the 1st party kexts to be in /System/Library/Extensions/ and for third party kexts to be in something like /System/Library/Extensions/Third Party/ instead of having them all in the root System Extensions folder? I think it would make a lot more sense, at least. Then you would be able to differentiate by location whether a kext is 1st or third party. Mac OS X's directory structure tries to keep things clean in other areas, so why not segregate kexts? I can see how this could have been a trait inherited from OPENSTEP, but that doesn't make it right.

2. Secondly, why isn't there a field in a kext that provides information on the company that produced it? At the very least the name of the kext should contain the vendor. Some Apple kexts have Apple in their names, but many more do not. Why couldn't they at least do the XML naming style that is used for plists?

I realize this is a pretty geeky concern, but does anyone else care about these two related issues?

[Simon]

Actually, wouldn't the right thing be to have Apple's extensions in /System/Library/Extensions and third-party extensions in /Library/Extensions. Isn't that the way it's designed for pretty much everything else anyway?

[Big Mac]

Yeah, you'd think so. The only thing is that since Kexts are core to the system the user shouldn't normally be looking at them, so I can see why they live in /System instead. They nonetheless shouldn't be intermingled together like that.

As for the identifiers for each Kext, they give name and version number. I don't see why Apple couldn't have added a Source column to those two. It annoys me, and I also think it's a potential security hole because it makes it harder to figure out who provided what.

[Hal Itosis]

> segregate kexts

FWIW, this command:
kextstat |grep -v com.apple

...will produce output similar to this:

Code:
Index Refs Address    Size       Wired      Name (Version) <Linked Against>
   45    0 0x6bc000   0x2b000    0x2a000    at.obdev.nke.LittleSnitch (2.1.08) <7 6 5 4 2>

[Art Vandelay]

Properly designed installers already place 3rd party kexts in /Library/Extensions. Blame the 3rd parties for putting their kexts in /System with Apple's.

[Big Mac]

Hal - thank you very much for that information. That's exactly what I was looking for in terms meta data. I don't understand why System Profiler fails to show that information.

Art - thank you for letting me know that some third parties use /Library/Extensions/.

[CharlesS]

Shameless plug: Pacifist has a feature called "Kernel Extension Report" that makes it easy to sort out which extensions are Apple-provided and which are third-party. It does this by checking the receipts to see which extensions Apple actually installed, rather than just using kextstat. This is important because some of the kernel extensions that come with the OS actually don't have com.apple bundle IDs - for example, the ACard drivers' IDs start with com.acard, EPSONUSBPrintClass.kext start with com.epson, and JMicronATA.kext starts with com.jmicron - so if one of those extensions is loaded at the time, kextstat will give you false positives. Pacifist also goes through the /System/Library/Extensions directory and checks all the kernel extensions there, even ones that aren't currently loaded, which kextstat won't do.

As for /Library/Extensions, applications can put them there, or can actually load kernel extensions from just about anywhere by using the kextload command. For example, DiskWarrior and VMWare Fusion both put their kernel extensions inside their app bundles. It's not really necessary to pollute /System/Library/Extensions, although many applications do it.

[Big Mac]

Great info. Glad I asked the questions.