site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com There isn't. KEXTs basically come from three places: 1) The cache 2) Autoloaded from /System/Library/Extensions 3) Explictly loaded by an application -- Terry _______________________________________________ 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... On Dec 27, 2007, at 12:29 PM, Kevin Elliott <kelliott@mac.com> 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. 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.). This email sent to site_archiver@lists.apple.com