On 10/7/20 10:10 PM, Tony Asleson wrote:

On 10/1/20 6:48 AM, Greg Kroah-Hartman wrote:

quoted

On Wed, Sep 30, 2020 at 09:35:52AM -0500, Tony Asleson wrote:

quoted

On 9/30/20 2:38 AM, Greg Kroah-Hartman wrote:

quoted

On Tue, Sep 29, 2020 at 05:04:32PM -0500, Tony Asleson wrote:

quoted

I'm trying to figure out a way to positively identify which storage
device an error belongs to over time.

"over time" is not the kernel's responsibility.

This comes up every 5 years or so. The kernel provides you, at runtime,
a mapping between a hardware device and a "logical" device.  It can
provide information to userspace about this mapping, but once that
device goes away, the kernel is free to reuse that logical device again.

If you want to track what logical devices match up to what physical
device, then do it in userspace, by parsing the log files.

I don't understand why people think it's acceptable to ask user space to
parse text that is subject to change.

What text is changing? The format of of the prefix of dev_*() is well
known and has been stable for 15+ years now, right?  What is difficult
in parsing it?

Many of the storage layer messages are using printk, not dev_printk.

So that would be the immediate angle of attack ...

quoted

quoted

quoted

quoted

Thank you for supplying some feedback and asking questions.  I've been
asking for suggestions and would very much like to have a discussion on
how this issue is best solved.  I'm not attached to what I've provided.
I'm just trying to get towards a solution.

Again, solve this in userspace, you have the information there at
runtime, why not use it?

We usually don't have the needed information if you remove the
expectation that user space should parse the human readable portion of
the error message.

I don't expect that userspace should have to parse any human readable
portion, if they don't want to.  But if you do want it to, it is pretty
trivial to parse what you have today:

	scsi 2:0:0:0: Direct-Access     Generic  STORAGE DEVICE   1531 PQ: 0 ANSI: 6

If you really have a unique identifier, then great, parse it today:

	usb 4-1.3.1: Product: USB3.0 Card Reader
	usb 4-1.3.1: Manufacturer: Generic
	usb 4-1.3.1: SerialNumber: 000000001531

What's keeping that from working now?

I believe these examples are using dev_printk.  With dev_printk we don't
need to parse the text, we can use the meta data.
So it looks as most of your usecase would be solved by moving to 

dev_printk().
Why not work on that instead?
I do presume this will have immediate benefits for everybody, and will 
have approval from everyone.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer