It was time for another experiment (make sure to read post #60 first). This time I was trying to:
1) Boot from a 4GB Kingston DataTraveler with all drives disabled in the BIOS (last paragraph).
2) Speed up the boot process of my 4GB Kingston DataTraveler.
3) Understand why boot-132 includes unused code, which could be used to speed up the boot process.
Let's jump right in. Here's what I did. I copied all kexts from /System/Library/Extensions/ to ~/Extensions/ (my local user folder) and started to remove one kext after the other. Well not really. Sometimes I removed 5 or 10 files at a time. Anyway. The next step was to create a fresh copy of Extensions.mkext for which I used the following terminal command:
sudo kextcache -v 1 -t -l -mkext2 /Volumes/USBBOOT/S*/L*/C*/c*/S*/Extensions.mkext ~/Extensions/
And after a few times... this is what I have. Here's my list of essential kexts (required to boot):
AppleACPIPlatform.kext [AppleACPIEC.kext removed] AppleAHCIPort.kext AppleAPIC.kext AppleFileSystemDriver.kext AppleFSCompressionTypeZlib.kext AppleHIDKeyboard.kext [Required for Apple keyboard / AppleBluetoothHIDKeyboard.kext removed] AppleHPET.kext AppleIntelCPUPowerManagement.kext AppleLPC.kext AppleMatch.kext [Removal = stuck at blue screen] ApplePlatformEnabler.kext AppleProfileFamily.kext AppleRTC.kext AppleSMBIOS.kext [Removal = slow boot] fakesmc.kext [Removal = stuck before blue screen] IOACPIFamily.kext IOAHCIFamily.kext IOHIDFamily.kext IOPCIFamily.kext IOPlatformPluginFamily.kext IOSCSIArchitectureModelFamily.kext IOSCSIParallelFamily.kext IOStorageFamily.kext OSvKernDSPLib.kext Quarantine.kext Sandbox.kext System.kext [Removal = KP]Now. Before you start counting... there are now only 27 essentials kexts left in Extensions.mkext [2.133.806 bytes]. And yes audio, LAN and everything else is still fully functional. But please note that I boot in 32-bit mode and haven't had the time to check 64-bit mode yet (which may fail so you are warned).
And this ladies and gentlemen tells me that the kernel doesn't really need Extensions.mkext (notably in the boot loader) nor that it needs all kexts in it... simply because it will load all required kexts anyway. Let me add that it loads Extensions.mkext right before the Apple logo is shown, and thus the larger the file... the longer it takes before the logo appears. No wonder of course because loading ~6MB extra data hurts. Even on a fast boot drive.
And while this experiment took off 10 revs i.e. booting from USBBOOT is now just as fast as booting from my hard drive, shedding new light on the matter, we still have to find a good balance between size and speed. But one thing is sure; limiting the number of kexts in Extensions.mkext does help. A lot even.
First. This was a fun experiment. And no regrets here, because now I can boot without any drive enabled in my BIOS. Which is cool for people who are still stuck with USBBOOT methods – hello RAID users? My initial thought (more a hope really) however was wrong. No. Extensions.mkext is not loaded twice! Which is too bad for us because now there isn't that much to gain for everyone. Anyway. It was not a complete waste of time. No sir. I think to have a much better understanding now, about how and why things are done in boot-132.
Also. It might still be a good idea to have a reduced copy of Extensions.mkext for normal boots. One with all unused kexts removed. That however is for you to find out since I already did this, and even before I started to work on this.
The SATA configuration in my BIOS is set to AHCI [other options are IDE and RAID] and all drives under BIOS menu: Main > AHCI Settings are set to "Not Installed". And booting is normally not possible due to the simple fact that the drives are undetected, but the setup I have here [on my USBBOOT] may enable me to boot with an unmodified copy of Chameleon. In fact it should work [why wouldn't it?] but I haven't verified it myself.
Oh and I spotted a few errors in kernel.log and had to restore IOCDStorageFamily.kext and IODVDStorageFamily.kext to fix them.
Oh bugger. I just noticed something! The following change wasn't made:
-orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable(); +orig_address = (struct SMBEntryPoint *) getAddressOfSmbiosTable();Which basically means that you have to fix this yourself. Well either that or wait for Revolution 0.6.19 to come out.