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

[Kay Sievers]

On Fri, Jul 8, 2011 at 16:54, Greg KH <greg@xxxxxxxxx> wrote:
> On Fri, Jul 08, 2011 at 05:45:47PM +0900, Nao Nishijima wrote:
>> This patch series provides an "alias name" of the disk into kernel and procfs
>> messages. The user can assign a preferred name to an alias name of the device.
>>
>> Based on previous discussion (*), I changed patches as follows
>> - This is "alias name"
>> - An "alias name" is stored in gendisk struct
>> - Add document to Documentation/ABI/testing/sysfs-block
>> - When the user changes an "alias name", kernel notifies udev
>>
>> (*) http://marc.info/?l=linux-scsi&m=130812625531219&w=2
>
> I don't like it and I don't think it will really solve the root problem
> you are trying to address, but as the patches don't touch any code I
> maintain, there's not much I can do to object to it.

I can only repeat what I already wrote in detail earlier:

This approach seems to papers over the problem which emitting and
parsing free-text printk() messages with much-too-dumb tools cause. It
seems to fix the symptoms not the cause.

You can already write a udev rule today that logs _all_ symlinks of a
device at discovery time, and any later kernel message can safely be
associated with all possible names of the blockdev. No kernel changes
needed, all possible names are covered. That also works good enough
with our current stone-age tools for anybody who is able to scroll
back to the last log udev message in that same log file.

There can be by-definition no default udev rules assigning a proper
single name to a block device. There is never a valid single name for
a disks, so udev can not ship anything like that in the default setup,
so this stays as a custom hack.

We absolutely need _structured_ data for logging and error reporting,
not only to solve this problem. Along with the current free-text
printk(), we would be able to attach classifications, device
error/sense data, firmware register dumps and anything
interesting-for-debug to the messages.

We can't solve that problem in the kernel alone. Structured data from
the kernel will need to feed a smarter userspace logger that can index
and classify messages, merge current userspace data into it, and
provides hooks for the system management to act on critical failures
and raise notifications.

Structured logging seems like the solution for this and also to many
other problems in this area. Single custom names pushed into the
kernel might cover some rather exotic use cases, but I think, is not
what we are looking for.

Kay
--
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/