Re: Determining which kernel extension is being opened
Re: Determining which kernel extension is being opened
- Subject: Re: Determining which kernel extension is being opened
- From: Terry Lambert <email@hidden>
- Date: Sun, 30 Dec 2007 13:11:19 -0800
On Dec 27, 2007, at 12:29 PM, Kevin Elliott <email@hidden> wrote:
Kext's are not loaded bundles from the perspective of
CFBundleGetBundleWithIdentifier. The function
KextManagerCreateURLForBundleIdentifier will map Bundle Identifier
to a system path, but it only works if the kext is at the top level
of /System/Library/Extensions (not in a sub folder, and not located
in a different directory). It's also user space only. I don't know
if you there is an equivalent function within the kernel.
There isn't.
KEXTs basically come from three places:
1) The cache
2) Autoloaded from /System/Library/Extensions
3) Explictly loaded by an application
In cases (2) and (3), the information on path is known to kextd, and
you can ask it (this is how kextstat works when you ask it for a
path). Case (2) includes non-required KEXTs loaded from an accessible
cache by kextd. It also includes kexts loaded from removable or
network media that has subsequently gone away.
In case (1), the information may not be inaccessible. For example, if
you did a netboot or a boot into an ASR restore image, the cache you
booted out of may not be accessible to the booted kernel and KEXTs
after the boot. In this case, only required KEXTs will have come from
the cache.
So the closest you can get is whatever kextd can tell you, and, due to
potential inaccessibility, that information could be incomplete and
unknown to kextd, or known but not useful (e.g. because you unplugged
the keychain drive from which it was loaded, etc.).
-- Terry
_______________________________________________
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