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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E1AE2CC.4010501@suse.de>
Date:	Mon, 11 Jul 2011 13:47:24 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Greg KH <greg@...ah.com>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	jcm@...hat.com, dle-develop@...ts.sourceforge.net,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	yrl.pp-manager.tt@...achi.com, dgilbert@...erlog.com,
	stefanr@...6.in-berlin.de
Subject: Re: [RFC PATCH 0/4] Persistent device name using alias name

On 07/08/2011 06:38 PM, Kay Sievers wrote:
> On Fri, Jul 8, 2011 at 18:15, Kay Sievers<kay.sievers@...y.org>  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@...e.de			      +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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/