Eric Sandeen wrote:
>It looks like it's already underway, at least as far as the author
>concerned. From http://gaugusch.at/kernel.shtml :
>Update as of 2008-03-15: Several maintainers in the Linux kernel
>started to reconsider their position on the feature. The patch as
>made a brief appearance in some development versions of the kernel
>2.6.25 (it has been reverted because deemed too likely to bring
>but a new approach, patch v0.9, is already available for next
then it is up to whether the patch is "clean" enough to go in the
I think the decision about a custom dsdt table in the kernel has
been taken long time ago. and the answer is the option that enables
the kernel to load a custom table. what the patch does is that it
pospones the loading of the table until the initram is loaded. so
the custom dsdt can be read from it.
If someone thinks the patch isn't good enough, then he should
suggest his own patch. but for now this is the only one available.
Either in the kernel or in the initram, in both cases we can load
our custom dsdt table. the only difference is that the kernel
recompilation takes about 30 mins (compared to the 2mins for the
repacking of the initram). I really don't see any objections to
simplifying this process.
Please, prove me wrong, but I'm just trying to make it easier to
run linux on my machine. And the patch simlifies this process.
PS: There is one more option:
Email the acpi-dev-team my custom dsdt so that they can include it
in the mainline kernel
. Since this is the "missing" code that
breaks my machine, it should be send as a patch for inclussion. And
this is the only way to make my hardware work. So maybe I should
email the kernel-acpi-dev-team
. As you can see, this is a lot
"dirtier" than the above solution. Any other ideas how to make my
Shop & save on the supplements you want. Click now!
fedora-devel-list mailing list