Re: [RFC PATCH 0/4] Persistent device name using alias name

[Hannes Reinecke]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/