On Fri, Aug 15, 2008 at 4:21 AM, Jan Blunck <jblunck@xxxxxxx> wrote: > On Thu, Aug 14, Tim Hockin wrote: > >> On Thu, Aug 14, 2008 at 8:44 PM, Greg KH <gregkh@xxxxxxx> wrote: >> > >> > What is wrong with what we have already agreed to standardise on here >> > people? dev_printk() for devices! It uniquely shows the device, what >> > driver is bound to it (if any), the bus id, and everything else. >> >> Part of the problem, imho, is the "if any" part. But I am more than happy to >> build on existing solutions. All the world is not a dev, though. I'd like to >> be able to report something like an OOM kill in (roughly) the same way as an >> ATA error, and I want (though could be talked out of) a way to tell these >> "events" (for lack of a better word) apart from plain-old-printk()s. > > I don't think that he wants to unify all the printk's in the system. I don't > think that reporting all errors "in the same way as an ATA error" makes any > sense. That would just lead to very stupid and unnatural messages for all > errors that are not like "ATA errors". Annotation of existing errors is a much > more flexible and feasible solution to that problem. Please don't misinterpret. I don't want to make other errors parse like an ATA error, I want to make the plumbing be parallel. I want one umbrella mechanism for reporting things that are more important than just-another-printk(). Because frankly, "parse dmesg" is a pretty crappy way to have to monitor your system for failures, and I am tired of explaining to people why we still do that. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
