On 07/08/2011 06:38 PM, Kay Sievers wrote:
On Fri, Jul 8, 2011 at 18:15, Kay Sievers<kay.sievers@xxxxxxxx> wrote:
On Fri, Jul 8, 2011 at 17:54, James Bottomley
But hey,
you have the enthusiasm, propose it as a KS topic to get agreement that
we should do it and what the format should be and we can go from there.
Sure, I'll do that. If needed, I can even make half or a third of it
possible I guess.
Submitted it a minute ago.
I'd be willing to working on the design here, as it ties in rather
neatly with my goal of updating the SCSI debugging facilities.
printk() is easy to write, but basically impossible to impose any
type of checking/format whatever.
My all-time favorite here:
printk(KERN_INFO "error 1\n");
At least it got a 'KERN_INFO' thrown in there ...
So first step would be to reach an agreement _what_ printk() et al
is supposed to convey to userland.
Informal only? Informal, but traceable to the origin?
Should the origin be the internal
structure/subsystem/device/whatever generating the error?
Should the origin be persistent across reboots?
And, tied to that, what the supposed audience for printk() is:
Programs? Syslog? Humans?
Once we have an agreement here we can then go about and code the
required pieces. But currently the main problem is that there are
different ideas of what printk() is supposed to do.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
