15/03/08 20:21, Linus Torvalds wrote/a écrit:
> 
> On Sat, 15 Mar 2008, Tilman Schmidt wrote:
>> Sorry to say, it doesn't. That is, it does shut up the warning I
>> reported, but there's a new one appearing now instead, three lines
>> later.
> 
> 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=9a9e0d685553af76cb6ae2af93cca4913e7fcd47
> 
> for details if you aren't a git person.
Hi,
It's a pity, I had just nearly finished a new approach. Instead of
relying on populate_rootfs() and the filesystem infrastructure, the new
approach directly finds the file in the initramfs. With
unpack_to_rootfs(), it turned out to be rather straightforward. Attached
 is a half-tested version of the patch (it boots and works but I haven't
compiled without the option yet). Just in case you would like to change
your mind ;-)


> 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!
Indeed, this form of DSDT override would be the best. However, I have no
idea what is necessary to implement it. Len, does this approach sound
feasible? Where should I start looking at?

Eric