(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 driverdevelopers doesn't like that... They may tend to continue usingprintk() debug/error notification. (actually I hope them touse some notification API, like traceevent...)

Maybe, some kind of errors, like AER/MCE, easily move on tosuch smarter system. But I doubt other device-specific errorscan 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 ourproblem 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 thinkit can be solved if udev script is enough smart :-)