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