First, you say... I saw "config=" boot option in BootHelp.txt, and tried. It is not implemented in Chameleon-2.0-RC4-r684-src-AnV source code.
... so, why didn't you checked out Chameleon (Cham) from the repo and used it instead? AnV even has a branch there! I don't know what's in his booter that you need that's missing on Cham, but i'm sure you can patch it with whatever it is! "config=" is on Cham for ages and working.
Well, I did not know where the source code is, and as you can see in my post, I was not working on Cham, I was merely trying to fix up my DSDT to get rid of power management disabler kext. I implemented "config=" because of my needs, and after it's fixed up, I thought it's a good thing to feed back.
If you guys are agreeing, I'm happy to redo it with the tip of svn, which I just learned where it is.
Next, if i do understand what you want to do (load a diff config/set of files), there's no need to mess with Extra extensions loading code. Use ramdisks, they're not only for pre-boot CD's, you know!? I know, this is not well documented, in fact i don't see it documented at all! Before i started messing with Cham code, the only hint i had about this stuff was a brief zef's post on Cham site. I fail to understand why this is not documented yet?!...
Anyway, as it is we can mount/unmount, get ramdisks info, enable/disable bt(0,0) alias on ramdisks, all from the boot prompt. There's even a usage menu. Besides the usual files, ramdisks can have a RAMDisk.plist with "BTAlias=y/n" and "Info=bla bla bla" keys. Just check the code, it's all there (ramdisk.c).
Sounds good. I'll try using ramdisk.
I always screw up typing in the boot command, so simplest to me is, if I don't type in anything, I want to get back to the machine.
Also, I keep my "plan-b.plist" which points to the working DSDT/kexts, so even if I totally screw up, I can get back to machine with "config=b.plist". (b.plist is my plan B.)
Using ramdisk, and mounting it at the boot means that, if I don't do it right, I get back to KP at boot, which is not very appealing to me. Fewer key types are always better for me. I'm too lazy, and always go for fewer keystrokes.
Now, here is were your path crosses mine. Another stuff that's not well documented and that i didn't had a clue how it worked until messing with the code... OverrideConfig. Messed with my mind a lot of times
overriding my overrides. But, mix this stuff with the ramdisks and you have all you need for your purpose.
I totally agree with you about this needing some "face lifting" and your bit of code for this (or something like it) is probably the way to go. I went as far as adding a Boot.plist key to disable/enable OverrideConfig and keeping only the paths i wanted to be overrided. I'm still a noob at this code stuff so, i can't write code like the one you did for this, but it sure crossed my mind. In the meantime i had to turn my attention to other stuff but i've been back at it again the past few days.
Before starting to fix up SSDT, I did not want to work on Cham, so I even sent a feature request to AnV for being able to exclude (not load) kexts, knowing that I can probably implement myself if I wanted.
The override config, as in the original code, was designed to augment two boot.plists. For the user's perspective, this is actually hard to use, because, although you know your override boot.plist, but, you don't know where the default boot.plist comes from, because the boot loader looks into many locations to load the default boot.plist.
So, I ended up filling in "everything" into the override boot.plist, since it's the only way to gurantee Cham sees what I want it to see. This is the side-effect of "augmenting" -- you cannot take value out from the default boot.plist.
By replacing the whole contents of boot.plist with override, you are now in the driver's seat.
The code happens to be much simpler.
I've been cooking this post for hours.. i was going to be a bit bitchy with you but, i decided to think a bit more and this OverrideConfig stuff started to got into me. Anyways, being bitchy is not productive
so, i'm on to try to merge your code with what i have. Will feedback asap...
Meanwhile, feel free to post or pm any question, doubt... whatever.
See ya later.
p.s.: This one is for anyone who knows... Wtf is a "ramdisk aliased as bt(0,0)"??
Again, I'm happy to feed the feature back to Cham, as I do really appreciate Voodoo and other people's work, letting me run my Hacks. Let me know if you want to me to produce a new set of diff from the source code.
Thanks.
P.S.
I'm still battling with this completely busted SSDT on my Abit's MB (it has no _CST). I've been trying to make up the c-state from air, and not surprisingly, it does not work.
![Undecided :-\](http://forum.voodooprojects.org/Smileys/default/undecided.gif)