[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: