(2011/06/17 8:04), Kay Sievers wrote: [...] >>>>>>> So as userspace tools will still need to be fixed, I don't see how >>>>>>> adding a kernel file for this is going to help any. Well, a bit in that >>>>>>> the kernel log files will look "different", but again, that really isn't >>>>>>> a problem that userspace couldn't also solve with no kernel changes >>>>>>> needed. >>>>>> >>>>>> This is true, but I think for the small effort it takes to implement the >>>>>> feature in-kernel compared with what we'd have to do to the >>>>>> distributions to get it implemented in userspace (we'd need klogd to do >>>>>> the conversion for dmesg ... I'm entirely unclear what we need to modify >>>>>> for /proc/partitions, etc.) the benefit outweighs the cost. >>>>>> >>>>>> Additionally, since renaming is something users seem to want (just look >>>>>> at net interfaces), if we can make this work, we now have a definitive >>>>>> answer to point people at. >>>>> >>>>> Renaming is something that we do NOT want to do, as we have learned our >>>>> lesson of the network device renaming mess. And as Kay pointed out, we >>>>> already have an "alias" name there, which no one uses. >>>> >>>> Look at this as an opportunity to get it right. The original proposal >>>> was for renaming. By iterating over the actual requirements, we have it >>>> reduced to simply having the kernel print a preferred name. I think >>>> that's a nice achievement which we can point other proponents of >>>> renaming to as they arise. >>> >>> Sure, we absolutely don't want renaming, and we can provide countless >>> solid technical reasons why we should not allow it to happen. But I'm >>> also pretty sure, we also don't want just-another-single-name to put >>> somewhere in the kernel. >> >> I understand why we don't want renaming. However, the technical reason >> why we want a preferred name is that it's often associated with a name >> printed somewhere on the box (say a label on the disk enclosure, or >> ethernet port). Not being able to use this name to address the device >> is a usability issue which annoys the enterprise enormously. >> >> So if we stop there, regardless of solution (in-kernel or fix all >> userspace), does everyone see what the actual problem is? > > I don't think that solves the problem, no. We need _smart_ userspace > with a debug/error message channel from the kernel to userspace that > pops out _structured_ data. Userspace needs to index the data, and > merge a lot of userspace information into it. If that is possible, I think it's so helpful. But most of driver developers doesn't like that... They may tend to continue using printk() debug/error notification. (actually I hope them to use some notification API, like traceevent...) Maybe, some kind of errors, like AER/MCE, easily move on to such smarter system. But I doubt other device-specific errors can do that too. There are so much specific kind of errors... > Adding just another single-name to the kernel just makes the > much-too-dumb free-text printk() a bit more readable, but still sounds > not like a solution. Pimping up syslog is not the solution to this > problem, and it can't be solved in the kernel alone. I agree with you that the _smart_ error notifier can solve our problem too. However, we can't jump into it directly. And just making printk() readable helps us A LOT! >>>>> So again, I really don't like this, just fix the userspace tools to map >>>>> the proper device name that the kernel is using to the userspace name >>>>> the tool used, and all is fine. This has been done already today, >>>>> succesfully, by many of the big "enterprise" monitoring systems that >>>>> work quite well on Linux, proving that this is not something that the >>>>> kernel needs to provide to implement properly. >>>> >>>> Well, it's expediency. Sure we could try to patch the world, but I >>>> think the simple patch of getting the kernel to print a preferred name >>>> solves 90% of the problem. Sure there is a long tail of userspace >>>> components that needs fixing, but that can be done gradually if we take >>>> the kernel route. If we go the userspace route, it will be a long while >>>> before we even get to 50% coverage. >>> >>> I need to ask again ask for an explanation why logging all symlinks at >>> device discovery from udev, does not solve exactly this problem. With >>> that tag in the syslog message stream, all later kernel names can be >>> safely associated with _all_ the current device names in question, >>> until the next tag from udev is found. >> >> So if the user has one preferred name, us logging all the names (and we >> have quite a few for disks) doesn't really help because the user might >> want to choose a different name. However, even if we assume they choose >> one of the current names, they still have to do the mapping manually; >> even if they have all the information, they can't just cut and paste >> from dmesg say, they have to cut, edit the buffer to put in the >> preferred name and then paste ... that's just one annoying step too far >> for most users. I agree that all the output tools within reason can be >> fixed to do this automatically, but fixing cat say, just so >> cat /proc/partitions works would never be acceptable upstream. >> >> The reason for storing this in the kernel is just that it's easier than >> trying to update all the tools, and it solves 90% of the problem, which >> makes the solution usable, even if we have to update tools to get to >> 100%. > > I don't think we can even solve 10% of the problems that way. It's > just a hack that makes stuff a bit more pretty, but doesn't provide > any reasonable solution to the problem. I doubt we can even make a > simple use case out of it, what name to put into that field for a > multipath setup. Good point! we have to consider multipath case in document. Perhaps, we need a special naming rule in that case. I think it can be solved if udev script is enough smart :-) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@xxxxxxxxxxx -- 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
