I agree with Linus' decision to revert/disable this feature. I think it is appropriate to muck with this in -mm, but not in -rc6 Kudos to Christoph, who recommended we revert it back at -rc2. > > What's the problem with just loading a new DSDT later? Potentially as in > > *much* later: including when user-space is all up-and-running? I don't think re-loading the DSDT at run-time would be practical. First, booting with the OEM DSDT may nullify the benefit of overriding the OEM DSDT -- the damage may have already been done. Secondly, unwinding everything that depends on the DSDT is on the order of kexec or suspend/resume. We're talking about all the stuff that PNP does at boot time, plus device discovery and driver binding. The feature on the table here is an initrd DSDT override. We already have the ability to statically compile a DSDT override into the kernel image. That capability is sufficient for kernel developers. The initrd version of the DSDT override is really for one scenario. Somebody who has a BIOS that even Windows can't deal with -- so no amount of "Windows bug compatbility" will help Linux with it. They must be capable eough to generate or acquire a modified DSDT. They must be unwilling/unable to re-build their kenrel from scratch each time they update it. Eg. following debian unstable updates etc. I think that customer deserves support, particularly because they get bragging rights that Linux works better on a box build for Windows than Windows does:-) However, I don't think there are enough customers like this to justify a huge effort that would add risk to Linux. -Len -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
