Re: sub-KEXT question
Re: sub-KEXT question
- Subject: Re: sub-KEXT question
- From: Kevin Brock <email@hidden>
- Date: Mon, 09 Feb 2009 11:20:23 -0800
Nik Gervae wrote:
For a given bundle identifier, the kext system tries to
load only the highest version found, and does not fall back to trying
earlier versions. This is true of the kernel itself, of kextd, and of
kextload -b. If you use kextload with a kext's filename, the exact kext
named will be tried.
Plugins are meant only as a packaging convenience, and have nothing to
do with how we look up kexts by bundle identifier. I'm not sure what
behavior you were expecting by using a plugin vs. installing two kexts
with different filenames but the same bundle identifier...the result
would be the same either way.
I know this. Please read my message again. The problem was that the
Apple sample, which follows all of the rules you give in your email,
fails to load with the given error.
>From the document in the sample:
Supporting Multiple KPI Versions
--------------------------------
The user client in this sample demonstrates both the legacy kernel
programming interface (KPI) that supports 32-bit user processes and the
current KPI that works with both 32-bit and 64-bit user processes. (The
current KPI was added in Mac OS X 10.5.)
Because there is no weak linking in the kernel, there is no way to
build a single binary that uses KPIs added in a newer version of Mac OS
X while maintaining binary compatibility with older versions of the OS.
The way to solve this problem is to take advantage of the "sub-KEXT"
feature of the kernel extension loading mechanism. When the system
enumerates all of the KEXTs in /System/Library/Extensions, it also
looks in each KEXT for a Contents/PlugIns directory. If that directory
is present, the system also enumerates any KEXTs found there. (This
search is not recursive; only KEXTs at the root of
/System/Library/Extensions are checked for sub-KEXTs.)
This sample builds a main KEXT using the Mac OS X 10.5 SDK and
specifying a deployment target of Mac OS X 10.5. This KEXT can use any
KPIs that were added in that OS version. The sample also builds a
sub-KEXT using the Mac OS X 10.4 SDK and specifying a deployment target
of Mac OS X 10.4. Both KEXTs are built from the same sources, using a
subset of the availability macros to conditionally compile code which
can only run on one of the target OS versions.
Next is how to control which KEXT is loaded on which OS version. It's
trivial to keep the Mac OS X 10.5 KEXT from loading on earlier versions
by specifying dependencies on later version numbers in the KEXT's
OSBundleLibraries property. However, this technique won't work in the
reverse scenario because much kernel code in a newer OS version will be
binary compatible with older releases. Instead, this sample uses the
IOProbeScore property to break the matching tie between the main KEXT
and sub-KEXT.
This sample does not do what it claims to do... If you try to load
this on OS 10.4 it fails, with the error I gave.
Here's what I did:
1) Fresh Mac, shipped with OS 10.5.6 installed
2) Install Xcode
3) Download SimpleUserClientSample
4) Build sample with no changes.
5) Try to run sample on 10.4 system
6) Fails with error in original email.
I believe the common recommendation in this scenario is to
use separate bundle identifiers so both driver kexts match and get load
requests. If any fail to load because of OS version incompatibilities,
the rest will then be ranked by probe score.
I know this as well. The sub-KEXT has a separate bundle identifier.
Please look at the sample in question. It's available on the Apple
site.
http://developer.apple.com/samplecode/SimpleUserClient/index.html
Kevin Brock
Nik Gervae
Kext Management Engineer
Apple Inc.
On 05 Feb, 2009, at 15:01, Kevin Brock wrote:
I was looking at sub-KEXTs as a possible way
of handling a kernel version dependency, and took a look at Apple's
SimpleUserClient sample.
I build it out of the box, with no changes (on a 10.5.6 system with
Xcode 3.1.2), put in on a 10.4.11 system and got:
"com.apple.kpi.iokit" =
"A compatible version of this dependency cannot be found"
and so forth for all of the dependencies.
I looked at a more detailed attempt to load (kextload -v 6) and saw
that
a) the loader saw the main KEXT and the plugin (SimpleDriver_10_4) and
recognized both as valid KEXTs
b) the loader looked for dependencies only for the 10.5 version. Never
checked for the other one.
This isn't code I modified, this is Apple's sample, downloaded and
built with no changes...
Do sub-KEXTs actually work? If so, does anyone have an idea why
Apple's sample isn't loading for me? Is there some weird processor
dependency? (the 10.4 system is a G5)
Kevin Brock
email@hidden
_______________________________________________
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
|
_______________________________________________
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