Re: Upgrading a ROM based KEXT
Re: Upgrading a ROM based KEXT
- Subject: Re: Upgrading a ROM based KEXT
- From: "Satyam Lad" <email@hidden>
- Date: Mon, 30 Oct 2006 10:29:42 +0530
Yes my New KEXT is present in the Extension.mkext file which i am able to be see using mkextunpack utility.
If i delete the file /System/Library/Caches/com
.apple.kernelcaches/ and reboot my new KEXT gets loaded.
The kexload -tn returns no error or warning. It says "myProd.kext" appears to be valid.
And the spaces you mentioned in info.plist are due to the copy paste i had done, those are not present in the original
info.plist
Is there a way to peek into the kernel caches?
How do we proceed ahead?
-Satyam.
On 10/28/06, Dean Reece <
email@hidden> wrote:
On Oct 28, 2006, at 1:14 AM, Satyam Lad wrote:
Hi Dean,
Yes my new KEXT which is in the " /S/L/E/ " folder gets loaded in safe boot.
I think that my new KEXT is not getting cached but the KEXT from the ROM is getting cached.
You can use the /usr/sbin/mkextunpack utility to see what is getting cached in /System/Library/Extensions.mkext, though the kernel cache (which you are booting from) doesn't have a corresponding unpack utility.
Another experiment to run to see what is going on with the caches is to get the system into the failing state, then remove all the files in /System/Library/Caches/com.apple.kernelcaches/ and reboot. That gets rid of the kernel cache and the system should fall back to the mkext cache. If the reboot picks up the right driver, that means the correct driver is getting into the mkext cache but not the kernel cache.
What can be the possible reasons for a KEXT from /S/L/E/ not getting cached when a lower version of driver is present in the cards ROM?
I'm not sure - generally, any kext that is loadable is also cacheable. There aren't any special properties that effect this. It is possible that something about your kext is acceptable to the boot-time driver loader, but is confusing kextcache, though that would probably be a bug on our side since the two should accept or reject kexts identically. What happens if you run "kextload -tn" on your kext - does it emit any warnings or errors?
I have seen version.plist in almost all systems default KEXT's in /S/L/E/ folder, but this version.plist is not present in my KEXT. What is the use of version.plist? Is this affecting in my case?
version.plist is placed in all bundles (not just kexts) by Apple's build system. It is not used at all by the kext management system and is not necessary. I believe it is used by software update to make sure it doesn't install an older bundle over a newer one, but I'm honesty not certain.
Is it that we are missing something in our info.plist file:
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>myProduct</string>
<key>CFBundleIdentifier</key>
<string>com.myCompany.driver.myProduct</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>2.0</string>
<key>IOKitPersonalities</key>
<dict>
<key> myProduct</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com. myCompany.driver.
myProduct</string>
<key>IOClass</key>
<string> myProduct</string>
<key>IONameMatch</key>
<array>
<string>myCard</string>
</array>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
</dict>
</dict>
<key>OSBundleLibraries</key>
<dict>
<key>com.apple.iokit.IOATAFamily</key>
<string>1.0b1</string>
<key>com.apple.iokit.IOPCIFamily</key>
<string>1.0b1 </string>
<key>com.apple.kernel.iokit</key>
<string>
1.0b1</string>
<key>com.apple.kernel.libkern</key>
<string>1.0b1</string>
</dict>
<key>OSBundleRequired</key>
<string>Local-Root</string>
</dict>
</plist>
PLEASE COMMENT.
The plist above looks complete, though of course you will fill in acceptable names before you ship this, right? Please tell me you don't have ROM drivers in the field with a class name of "
myProduct". CFBundleIdentifier and IOClass must be globally unique, so you should use something like com.<myco>.driver.<thisprod> and com_<myco>_<thisclass>, (where you substitute suitable strings).
I did notice there are spaces in odd places in the plist above. In particular, the following one would create problems:
<string>com. myCompany.driver.myProduct</string>
Since that is a different bundle ID than is specified higher up in the file. If the "wrong" driver has the bundle identifier with a space in it and the right driver doesn't, that could completely explain the problem you are seeing (since they are different identifiers, and thus will compete against each other at match time).
I also see the following additional extraneous spaces:
<key> myProduct
</key>
<string> myProduct</string>
<string>1.0b1 </string>
On second though, perhaps you have pasted generic names back into this plist to protect the identity of your product (and pasting text on Mac usually inserts spaces if it thinks it should)...
Are there any other parameters to be set to increase the probe score?
The probe score is not your problem. The kext system will not match/load more than one driver with a given CFBundleIdentifier. For some reason, the wrong version of your kext is being picked up by the kernel cache. The right version could have a much higher probe score but it would make no difference since it is never getting probed.
Cheers,
- Dean
-Satyam.
On 10/28/06, Dean Reece <
email@hidden> wrote: On Oct 27, 2006, at 12:27 PM, Michael Smith wrote:
> On Oct 27, 2006, at 11:20 AM, Satyam Lad wrote:
>> The probe score will always be the same as the info.plist is the
>> same for both the KEXT's.
>> The only difference in both the KEXT (in terms of
info.plist) is
>> of "CFBundleVersion" property. The new KEXT has a higher number
>> then the older (ROM) KEXT.
>
> This won't achieve your desired goal; version numbers are not
> considered when matching, only the probe score counts.
>
> If you want the kext to win vs. the ROM, you need to ensure the
> kext has a higher probe score.
Actually, thats true only if the two kexts have different CFBundleIdentifiers. The way it is *supposed* to work in this case is as Satyam is attempting The kext managmenet system will collect all the versions it can find for any given CFBundleIdentifier and attempt to use the latest version.
The fact that it is working as expected on the first reboot tells me that he has it mostly working correctly. The fact the subsequent reboots use the ROM kext indicates that perhaps his newer kext isn't getting included in the kext cache.
What happens if you safe boot (hold the shift key down), which bypasses the caches and goes back to scanning for individual kexts. Does it get the newer kext then?
Cheers,
- Dean
_______________________________________________
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