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: <4E17F121.3030601@hitachi.com>
Date:	Sat, 09 Jul 2011 15:11:45 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
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,
	yrl.pp-manager.tt@...achi.com, dgilbert@...erlog.com,
	stefanr@...6.in-berlin.de, hare@...e.de
Subject: Re: [RFC PATCH 0/4] Persistent device name using alias name

(2011/07/09 1:15), Kay Sievers wrote:
> On Fri, Jul 8, 2011 at 17:54, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> 
>> Yes, we did.  Everyone agrees structured logging would be the best long
>> term solution.  However, it's at least 10x the work presented here, plus
>> it would be a long process getting everyone to agree.
> 
> Maybe even 100 times :)
> 
>> This looks like a
>> good 95% interim solution and it can be removed when structured logging
>> makes everything "just work(tm)".
> 
> I don't really see that. I think it does not add any real value on top
> of a simple udev logging at device discovery.
> 
> You would see that in the log:
>   [78441.742634]: udevd: sdc: \
>   disk/by-id/ata-INTEL_SSDSA1M080G2GN_CVPO0363030V080EGN \
>   disk/by-id/scsi-SATA_INTEL_SSDSA1M08CVPO0363030V080EGN \
>   disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 \
>   disk/by-id/wwn-0x50015179593f3038
> 
> and know exactly _all_ names and all identifiers of the disk at that time.
> 
> Then you see this:
>   [78441.742634] storage: really bad things happened to: sdc
> 
> and with the earlier message we have all we need to know without any
> pretty-name hacks.

Hmm, yes, we CAN do that, if user carefully sets the udev log-level
high, and saves udev log every boot or device change.

I think the main point of this attempt is to reduce the cost of
those operation, as like as users have done with old un*x way.

If we can use a same device name for same device and can see the
same name on the kernel log, we don't need to pay additional cost
for searching and picking correct entry from udev log.
Of course, it needs updates on some tools too.


> All that can be done today already with a single udev rule, even on
> many years old distros.
> 
>> I have also seen a couple of other attempts at structured logging which
>> both failed when the people proposing the patches realised how much work
>> it actually was, so I'm a bit sceptical we'll ever get there.
> 
> The more paper-over we add the more unlikely it gets. That's what I fear. :)
> 
>> 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.

BTW, I'm also interested in that structured error events, from the long
term view and viewpoint of tracers :)
I think we could expand current TRACE_EVENT macro to define those error
events.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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/