Hi! > >>> FIRMWARE_BUG_ON(severity, description, component); > >> > >> Yes, please. > > I'm not excited about maintaining > maintaining linux-as-a-firmware-diagnostic -- > particularly when... > > 1. it clutters the code for normail machines > 2. finding the bug is pointless, because even > if you fix one machine, you are guaranteed to > not fix all machines and thus must maintain > the workaround anyway. Well, at least we can make sure new machines are okay. Plus, it is nice to know how common hw/BIOS problems are. > >> I'd also like HARDWARE_BUG_ON(), with similar usage. > >> > >> With all the preload-linux-on-foo project, we have some > >> chance to make > >> BIOS vendors fix their stuff if we can easily diagnose errors in > >> there. > > These customers should be running > http://linuxfirmwarekit.org/ > > We do maintain some degree of "high-road ACPI spec checking" > with the "acpi=strict" boot option. If we do more of this, > I think it should stay under that option. That's okay with me, but it would be nice to have printk() markup, so that we can tell BIOS/hw bugs from normal kernel messages. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
