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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
