overdue-scratch

Author Topic: [PATCH] config= from boot command prompt, and AdditionalExtensions  (Read 16089 times)

0 Members and 1 Guest are viewing this topic.

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Hello,

background: I'm trying to get rid of IntelCPUPMDisabler and SleepEnabler kexts by putting in SSDT.
So, I wanted to load/not load them from the boot prompt of Chameleon.
I saw "config=" boot option in BootHelp.txt, and tried. It is not implemented in Chameleon-2.0-RC4-r684-src-AnV source code.
I also needed a feature to have a secondary Extensions folder so that I can control the loading/not loading of extensions in the folder.

So, I implemented both. From the command prompt, you can say
config=plan-b.plist
and the Chameleon loads "/Extra/plan-b.plist" instead of com.apple.Boot.plist.

Also, in the plist file, you can add a key/value to designate the folder to load the Extensions from.

  <key>AdditionalExtensions</key>
  <string>/Testing</string>

Chameleon loads /E/E, and then loads kexts from /Testing/Extensions.

With that, I can test a set of extensions from the boot arg.

Here is the diff from AnV's sources.
Note that, along the way, I purged "override config" part of code since it really needed a refactoring.
It is far simpler and easier to understand what's going on.

Thanks, AnV!

« Last Edit: April 10, 2010, 11:59:49 AM by tennisgeek »

zef

  • Administrator
  • Posts: 265
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #1 on: April 10, 2010, 01:09:23 PM »
Note that, along the way, I purged "override config" part of code since it really needed a refactoring.
It is far simpler and easier to understand what's going on.

Hi tennisgeek,

Removing the override config featrue prevents the booter to use the selected partition's boot.plist. I agree that the implementation is not a "gem" ;P but it worked pretty well. I'm thinking about to implement an "ExtensionsPath" option instead of the "AdditionalExtensions". This way the user can change the default path via plist or boot prompt.
« Last Edit: April 10, 2010, 01:16:12 PM by zef »
ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #2 on: April 10, 2010, 09:34:23 PM »
First off, config= boot parameter working means that you can override the default boot plist from the boot volume, with the default of "/E/c.a.B.p", or whatever you want in the /Extra folder with "config=", which BootHelp.txt probably wanted it to happen. It is certainly what I expected when I saw it.

Before the change, once the value is present in the default boot.plist, you could not take it out, telling Chameleon to not see it was a little tricky.

Since loadSystemConfig and loadOverrideConfig are rolled into one, rather than holding onto both plists, I decided to simply replace the default with the override. Therefore, you cannot use the override boot.plist to supplement the default boot.plist.

Sometimes I have no idea where the boot.pliist value is coming from, and I had to bang my head not being able to override the kernel parameter for booting. Also, this supplementing sounds good on paper, but it's actually harder to use for me when I want to take the value out from the default boot.plist.

For the name of "AddtionalExtentions", I don't care the name as long as the functionality is fed back to Chameleon. "ExtentionsPath" is fine with me. My intention was that the name implies that the path designated is "secondary" location to load the kexts from.

With the changes, I can put fakesmc.kext in /E/E, Power management disabler in /Testing/Extentions.
/E/c.a.B.p includes the /Testing for loading, and /E/no.plist does not load /Testing/Extentions.
I can boot with "cofnig=no.plist". When I get KP with HPET because SSDT I tried does not work during booting, I hit reset, do nothing and I can get back to machine.

diebuche

  • VoodooLabs
  • Posts: 30
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #3 on: April 10, 2010, 10:11:44 PM »
So config= would basically be there to make testing new kexts easier, right?

To be honest i feel it's a bit redundant:
first, you can easily create bootable usb sticks to test any c.a.B.p, DSDT or kext configurations.
Cham already has way to many possible parameters etc
and lately a lot of kexts have been rendered unnecessary by better DSDTs, for example there are a lot of systems for fakesmc.kext and legacyhda.kext are the only needed ones..

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #4 on: April 10, 2010, 10:48:55 PM »
So config= would basically be there to make testing new kexts easier, right?

To be honest i feel it's a bit redundant:
first, you can easily create bootable usb sticks to test any c.a.B.p, DSDT or kext configurations.
Cham already has way to many possible parameters etc
and lately a lot of kexts have been rendered unnecessary by better DSDTs, for example there are a lot of systems for fakesmc.kext and legacyhda.kext are the only needed ones..

To get to the point where you want to have just fakesmc.kext, which is the holy grail of hack, having actually "config=" working helps testing out. Right now, Cham does not have way of excluding kexts.

Using USB stick works for you, I'm happy for you. To me, using disk is much faster, and fighting with stinkin' SSDT was killing me.

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #5 on: April 11, 2010, 10:11:10 AM »
Hi there @tennisgeek.. Have some words to say about this as i've been all over it for last month or so, not quite for the same reasons as you but also.
Well,you have a point there and you approached the problem in one possible way but, not the most suitable one in my opinion.
First, you say...
Quote
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.

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).

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.

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 :P 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)"?? :o
I'm guessing it becomes bt(0,0) but it's clear to me. EDIT: figured!
« Last Edit: April 12, 2010, 11:37:35 AM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #6 on: April 11, 2010, 07:19:40 PM »
First, you say...
Quote
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 :P 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)"?? :o

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.  :-\

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #7 on: April 11, 2010, 08:08:40 PM »

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.

Well, it took me a cup of coffee to redo it. Here is the diff from the svn head of Chameleon trunk.
Thanks.

Back to more making up of SSDT...

-- TG

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #8 on: April 12, 2010, 02:54:45 AM »
Back.. @Tennisgeek, never mind if i still "sounded" like bitching at you. I was honest about it.. i had an almost finished post when i realized i was going to be a prick with you :( my apologies for that. Ok, let's leave that behind...
Thanks for the port to trunk.. will take a look at it after posting.
For now i'm just going to comment your post.
Quote
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.
Mounting a ramdisk named planB.dmg at boot prompt is as easy as typing: ?rd m /path/to/planB.dmg. If you name it preboot.dmg and place it on Extra it will be loaded automatically.
Quote
... 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.
The paths the booter searches for "main" Boot.plist are these, by that order. The first found is the one used. Then there are the paths were the booter searches for override Boot.plist. As OverrideConfig is enabled by default, any boot.plist found there will replace (override) or add content to main Boot.plist, depending on the keys on it, except for Kernel & Kernel Flags keys. For instance:
- if the override has a key that's not on the main Boot.plist, that key will be added.
- if there's a "override key" on the override Boot.plist like DSDT=blabla, that key will override an identical one present on the main Boot.plist.

So, there's not only "augmenting" going on here, there's actual replacement!
I agree this is a bit complicated at first look. Like @diebuche mentioned, there are already to many parameters to handle but, sometimes the only way to solve things is by adding more. My advice is, try it and see how it works. I started testing with ramdisks but as i mentioned, i had to look at other stuff first. I still have many doubts i can only clear with more testing and eventually talking to someone with the knowledge. One thing at a time... :)
My intention is to figure out this stuff as much as possible, then document it and post it here, so we all can have a say and get to a conclusion that suits both the end user and the dev.
We're basically messing with the same stuff, just for different motives.

See ya later..
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #9 on: April 12, 2010, 08:17:27 AM »
Azimutz, thanks for looking it at it, and pointing out what I missed, the dirspec difference between default/override config.
I submit the fixed up diff, with the dirspec switches between default/override. (I just copied the dirspec from original override config side.) My (tired from hacking SSDT) eye did not see the difference and I was thinking "what the hell with these".

I have not had chance to try the ramdisk.  (I just came back home, had a beer after playing tennis. After all, I'm Tennis/Geek.)  With your post, I can see it's indeed very useful. Thanks.

ramdisk or not, as I said in previous post, the override boot.plist cannot "remove" key/value from the default boot.plist.
Once it appears in the default boot.plist, I have to put in a new value to override the default. In my case, I have to put in a bogus value for my "AdditionalExtentions" so that the kext loading is skipped. I do not like it at all.

Instead, I want/need to do is that the override boot.plist to hide/remove the value the default boot.plist has.

I really don't want to be a pain repeating over, but I had to bang my head, that I put in "AdditionalExtentions" in the /E/c.a.B.p, and "/Extra/a.plist" not have the AdditionalExtentions, boot with config=a.plist yet it still loads the kexts, screwing me over trying to test the new SSDT.
Because, the default /E/c.a.B.p's value is still alive until I had to put in a bogus value to "override" /E/c.a.B.p. That's when I realized that the "override" is not overriding the default boot.plist, it is merging/augmenting.  It is a form of override, but when I may or may not know where the default boot.plist came from (which I did not know when I was banging my head), I felt it's harder to use the override.

With working config=, it's even more so that you'd (at least me) want to see that the boot.plist you designated by config= takes over what Cham sees.

« Last Edit: April 12, 2010, 08:24:05 AM by tennisgeek »

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #10 on: April 12, 2010, 05:21:57 PM »
Ok, i think i got the last pieces of the puzzle i needed to clear my doubts :)
And i think i finally understand your problem correctly. Got a bit confused by all the file name abbreviations and so...
You did crossed my path completely and you're being screwed by the problem that lead me to look in Chameleon's code in the first place. Well, the two problems.

OverrideConfig can be messy, but down deep it's just annoying. For example: i'd set DSDT=/E/test.aml on the main Boot.plist on System's Extra, to test a graphics patch and reboot to messed up graphics. I reach for my trusty rescue media and i get the same messed up graphics :o now i'm confused and Wait=y didn't existed yet... the rest of the story you can imagine; the solution is simple, override at boot prompt the "DSDT override" on main Boot.plist. So, pretty annoying but not "deadly".

The stuff that's really messing with your testing can be a major disaster. Take a look at the driver loading code... as you can see on lines 186 & 198, the paths the booter looks at for Extra extensions have rules, "if is a ramdisk and isn't aliased as bt(0,0)" check rd(0,0)... etc... Now look at line 193, no rule for that one, that path is always checked! "/Extra/" tells the booter to check the selected boot volume's Extra folder and there ya go; in your case it's just some kexts you don't want to load, now imagine if one installs a bad kext on Extra confident that rescue media will always save the day!? ;) And to make matters worse, Extra extensions are the only files used by Cham, that don't have a override key.

I still have some testing, solitary brainstorming and code/comments cleaning to do, before can i diff and commit what i've been working on. I already mentioned the key i added to enable/disable "canOverride"; i also changed a bit the Extra extensions code, added more rules and changed it to a "goto -> tag" scheme, inspired by the new ACPI table search algorithm. Working on a Extra extensions override key too, but the way this is working i don't think it will be needed.
Anyway, that's not for me to decide all on my own!

I'm exausted :P going for a nap so i can work on this during the night when i get peace & quiet.
Will check in later.
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #11 on: April 12, 2010, 08:34:06 PM »
I still have some testing, solitary brainstorming and code/comments cleaning to do, before can i diff and commit what i've been working on. I already mentioned the key i added to enable/disable "canOverride"; i also changed a bit the Extra extensions code, added more rules and changed it to a "goto -> tag" scheme, inspired by the new ACPI table search algorithm. Working on a Extra extensions override key too, but the way this is working i don't think it will be needed.
Anyway, that's not for me to decide all on my own!

Azimutz,

Funny that "canOverride" actually came to my mind as well.
I gave a thought for a moment, started writing code for it, and I realized (a) I still cannot remove a key/value from the default boot.plist (b) with "canOverride", things gets even more complicated without understanding what's going on under the cover.

For me, it comes down to three features -- one is working "config=" in boot option, second is being able to remove a key/value from the default boot.plist with override boot.plist, the third is, with first and second in place, being able to not load kexts which the default boot.plist wants to load. My changes cover all three, and makes the code simpler.

Since you are working on the feature, I do not want to interrupt you but I'd want to persuade you to make things simpler, and I think canOverride, though I had the same thoughts, makes things harder to use.

Cheers,

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #12 on: April 13, 2010, 03:03:19 AM »
Yeah... from my perspective it's very very funny ;D and helpful! This topic, the timing, the reasons why and the way you approached the problem, etc... it's helping me sorting things out in my mind. Besides this topic, till this day i only read one other topic related to this, a few days ago here on the forums and a brief post some were. Let me try to fetch it...
Quote
Document Azi, document! (i read ya Rocksteady :) ).. i really gotta start doing it properly!!
I think i just found another related topic (or is it the same?? :P think i read it before). This one clearly matches my problem and makes it obvious that this was all an option, as i thought. And this is why my "perspective" is different than yours. What im trying to do is improve the initial perspective to one more suitable, using as much as possible the code already present (for learning purposes too ;) ).

You're too focused on removing! How about removing by adding? Consider this situation:
- let's say that the drive load "issue" is fixed with something like this (how i'm doing):
Code: [Select]
...
        if (gRAMDiskVolume && !gRAMDiskBTAliased)
        {
            // Check ramdisk.
            strcpy(dirSpecExtra, "rd(0,0)/Extra/");
            fd=FileLoadDrivers(dirSpecExtra, 0);
            if (fd>=0) goto eureka_fd;
        }...
...
        if ( (gBIOSBootVolume->biosdev == gBootVolume->biosdev && gBIOSBootVolume->part_no == gBootVolume->part_no)
            && !(gRAMDiskVolume && gRAMDiskBTAliased) )
        {
            // Check only selected root volume.
            strcpy(dirSpecExtra, "/Extra/");
            fd=FileLoadDrivers(dirSpecExtra, 0);
            if (fd>=0) goto eureka_fd;
        }...
...
eureka_fd:...

- "canOverride" is "disabled" by default and there's a "ConfigOverride" Boot.plist key to enable/disable it
- the only path on "loadOverrideConfig" is "rd(0,0)/Extra/com.apple.Boot.plist"

So, on your main Boot.plist you set ConfigOverride=y.
Next you grab your System's Extra folder, place it on a ramdisk named "test.dmg", get out the files you don't want to load, add other files you do want to load/override the default ones and edit the Boot.plist on it to something like:
Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DSDT</key>
    <string>rd(0,0)/Extra/dsdt.aml</string>
    <key>whatever</key>
    <string>bla bla bla</string>
</dict>
</plist>
Disable btalias on RAMdisk.plist and place the ramdisk at / or /Extra...
At boot prompt mount test.dmg: ?rd m /test.dmg
Use Wait=y to check the loaded paths.

What is the outcome?

On to more testing... this stuff is keeping me restless as hell  8)
Later...
« Last Edit: May 05, 2010, 05:34:04 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #13 on: April 13, 2010, 05:08:01 AM »
At boot prompt mount test.dmg: ?rd m /test.dmg
Use Wait=y to check the loaded paths.

What is the outcome?

I'll end up putting in the power management disabler kexts in /Extra/Preboot.dmg, because I want to type the least amount.

So, I'd do

?rd u
config=a.plist

That's not too bad, but I'd prefer my original, which was just "config=a.plist", unless I can load arbitrary ramdisk from the a.plist.

Could you please give a thought to how you'd want to control the booting process with "config=".

I understand that you are working on the boot.plist loading path order. But, you haven't mentioned anything with "config=" boot prompt, which probably someone else wanted as well, and took time to put in BootHelp.txt.

It makes sense to me that, once you use "config=" from the boot prompt, Cham follows the config exactly without borrowing any values from the default boot.plist.


tennisgeek

  • Observer
  • Posts: 15
  • If ur age < 30, I'm programing longer than ur life
Re: [PATCH] config= from boot command prompt, and AdditionalExtensions
« Reply #14 on: April 13, 2010, 05:20:36 AM »
You're too focused on removing!

LOL.

(a) Well, I'm trying to remove the kexts. I'm really jealous of my friend's hacks having just fakesmc.kext.
(b) I'm lazy and don't want to type more than 10 letters in the boot prompt. 
(c) Smaller code, less time to understand what's going on, easier to maintain.

Seriously, I'm constantly rebooting for testing out SSDT, and being able to switch plan A to B as little effort as possible is a good thing for me. The SSDT faking is seriously annoying and being forced to type the boot command is "one thing to add" to that.

BTW, the theme "DType" is gorgeous, and I'm pretty bummed that I have to type in the boot command. I'd really want a additional menu item "Test Mode" in GUI. Maybe I'll file a feature request.