From: Stefan S. <ssc...@gm...> - 2004-08-09 20:02:23
|
> Yes, the dsdt-in-initrd patch works. > Yes, it is perfect for the unfortunate but determined soul who > administers a variety of broken machines where they all run the same > kernel and require a different DSDT -- I really do feel sorry for that > person and look forward to the day they find non-broken hardware. I only use it on one machine and if I want to change the dsdt I dont want to recompile my kernel. > > But DSDT overrides are for developers, not end-users, not customers. > Nobody can support the OEM's firmware, or a modified version of it > except the OEM themselves. If a developer happens to fix an OEM's > firmware and sends the OEM the fix, that happy situation is purely > between the end-user and the OEM. Distros should absolutely never > be in the business of supporting hardware running modified firmware. Right, distros should not support it, but people who know what they do should have the ability to do it easy and w/o recompiling the kernel. > I think that one major Distro pulled the dsdt-in-initrd patch, and I > think it was a mistake for them to do so -- they can't support it. They do not need to support it - if people use it, its on their own risk. > That said, it is useful for developers to be able to override the DSDT. > There are two methods -- re-build kernel or re-build kernel and also > modify the initrd. the difference is I can do the second one without looking into the howto, because i know where my initrd is - in fact it is the DSDT.aml. For the first method I would need to know the place where to copy the dsdt - and always recompile/recopy/reinstall the kernel for minimal changes. > Kernel re-build is (I think) simple enought. I think the patch at hand > takes it from simple to trivial. > Kernel re-build + initrd update I dislike because it depends on the > existence of an initrd (not everybody uses has an initrd, I haven't used > an initrd in over a year), and worse, it depends on the format of the > initrd, which we don't control. Initramfs would be the solution here - why not use it as additional method? > > Anyway, I hope that my position, and the reason I haven't pulled the > perfectly functional and useful dsdt-in-initrd patch before is clear. Can you not just provide all possibilities, so that the user, sorry the "developer", can decide himself how he wants to override his initrd? |