I've reverted the whole thing. Or rather, since there were various small
fixup commits over time, and a simple revert doesn't really work, I ended
up just removing the option and the code that was conditional on it - that
way, if we really want to fight this out some time (after 2.6.25 is out)
or some vendor wants to use a known-broken option anyway, there's a simple
and fairly clean commit to revert the revert.
It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d...
for details if you aren't a git person.
But quite frankly I don't think that we even want to re-introduce this in
that form. If we really want to have a dynamic custom DSDT, I think we
should do the whole DSDT replacement *much* later by ACPI (like just
before driver loading or something like that).
If the BIOS-provided DSDT is _so_ broken that we cannot even get core
stuff like the CPU's going, I think it has more serious issues than any
custom DSDT will ever fix, but letting ACPI actually switch DSDT's at
run-time (instead of just replacing it when looking for it very very early
in the boot sequence) in order to work around some device issues sounds
reasonably sane.
So how about aiming to make that DSDT-replacement something you can do
from any kernel module, _after_ the original DSDT has already been parsed?
And then the whole "load it from initrd" turns into a regular thing that
we can do pretty early, but that we don't have to do quite _this_ early!
Linus
--
