Bug#251023: upstream status of acpi-dsdt-initrd patch
hey,
I did a little research this morning to try to formulate an opinion -
here's what I found:
* This patch is not upstream and is unlikely to go upstream.
The ACPI maintainer doesn't seem to doubt its quality, but rather
believes its a development tool and not something distributors can support[1].
* Fedora has chosen to follow upstream and not include this patch[2],
while SuSE, Ubuntu, and Mandriva do include it[3].
* There are cases where a different DSDT is necessary for our kernel
to work on certain hardware. A friend of mine gave me his real-life
example of a device where the DSDT reports the wrong interrupt
link. noacpi doesn't disable acpi-based interrupt routing. irqpoll
would work, but the performance hit is too high. A device quirk
could be added to the kernel to workaround this device, but this
device has a generic pci device/vendor and subsystem device/vendor,
so it would be at least difficult.
So it seems clear to me that we'd be alienating users by not including
this patch, but we'd also be introducing a feature we cannot support.
I don't believe that our patch acceptance guidelines[4] should make it
impossible for us to consider this patch. The "upstream" guideline
is there because we don't want to include sub-par code, and we don't
want to maintain a feature that we introduced but has been abandoned
upstream. I don't think either of these applies here, at least not
terminally. The patch appears to be pretty robus, though the coding
issues waldi uncovered should certainly be looked into, and I think we
could work with other distributions to continue maintenance of the
patch in the event that upstream drops it.
I agree with upstream/Fedora that this isn't something we can support
- if someone reports a bug, its quite possible its caused by their
hacked system firmware, and there's nothing in a bug report that would
tip us off to this. Of course, we deal with similar scenarios today -
non-free kernel modules and userspace-loaded firmware.
non-free kernel modules are dealt with using tainting, while
userspace-loaded firmware problem is just simply less likely to be
hacked. I think that it should be clear to our users that using this
is unsupported, and any bugs they report need to be reproduced w/o
loading DSDTs.
Would it be possible for us to add our own tainting signature for this
case? It seems to match well with the goals of tainting.
Documentation/oops-tracing.txt says:
"The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred."
And the use of tainting doesn't appear to be limited to modules -
the unsafe-SMP case identified by the 'S' in the taint signature is an
example.
I also wonder if ACPI upstream would re-consider including this patch
if DSDT-tainting was implemented?
[1] http://sourceforge.net/mailarchive/message.php?msg_id=9175150
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169014
[3] http://gaugusch.at/kernel.shtml
[4] http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
--
dann frazier
Reply to: