On Wed, Apr 29, 2009 at 02:28, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > On Tue, Apr 28, 2009 at 11:25:31PM +0200, Kay Sievers wrote: >> Don't know, the name is probably not the right thing, because it can >> be changed, The uuid might fit better. > > But why would changing the name be a problem? Because we would need to change the kernel name at the same time, including all the userspace rename processing, means "move" uevents. There is the rule, that kernel block device names and /dev names match, and the kernel log shows device names which translate directly to the primary device nodes. DM is not an exception here, all block device behave like that , and we like to continue that, and not make needless rules just to be special here. Also DM allows pretty stupid free-text device names, and names including spaces and control chars. This is not supported and users should not be able to provide such kernel names at all. Udev btw, does not allow you to use spaces, or other unusual control characters in device names for several good reasons. > What is fundamental here is the device number - that's all. There are many things that match on name strings. > E.g. Anything in userspace that opens /dev/something has to check that > what it actually opened still has the same device number, if it cares > about avoiding races. No, we don't go and change device node names for the same device number. You could do that with updated symlinks but not with the primary nodes. > If we can extend this field in-kernel and put the user's preferred device name > in there we'd gain the immediate big advantage of error messages produced > throughout the kernel using a name that the sysadmin can translate into > something they understand much more easily. Devices can have many names, also names which are not unique at all times on the same system. it might work in your specific case, but not for others. > "dm-vg1-lvol1" instead of "dm-13". Sure, if you get the kernel to have that as the name in /sys/block/, then it's fine. Btw, udev will replace your '|' characters with "_'. There is no free text in /dev today, especially not for user provided naming. > And this would be a big help to people I believe. (Although the dm name > can be very long, on most systems it's still quite short. The uuid on the > other hand is long and typically randomly-generated and meaningless to the > sysadmin.) > > Then any userspace packages would by default pick up a meaningful name - > something considerably more persistent and useful than dm-X. Sure, but again, if you want to do that for the primary device node and not for symlinks, please set the name in /sys/block/ to that name. We are not going to mess around here. > So my latest proposal would be: > 1) Change the kernel to allow longer names for block devices That should be easy. > 2) Change dm to insert dm-<name> into this field instead of dm-X That will only work reliably if you can not change the name on the fly. Otherwise it will get complicated to keep track of the devices. Possible, but a real mess to get right. > 3) Add an in-kernel interface to let dm change this name on request by the user It should be set before it is created, and not changed later. Also it is generally not recommended to let users specify any part of kernel device names. If you allow that, we will need to limit it to plain [a-zAZ-:.]. > 4) Adjust udev rules to create nodes as /dev/dm-<name> > (actually I'd still argue that /dev/subsystem/name is a better approach) No. The adjust the kernel device names, not the rules. > 5) Change all dm-based userspace tools to handle /dev/dm-* Sounds good to me. > 6) Change anything if there is anything in userspace that cares about those > /dev names getting changed on a live object and needs to react differently to a > CHANGE uevent. It would be "move", which I think you should not get yourself into the trouble supporting that. > And eventually perhaps: > 7) Phase out /dev/mapper (in a suitably-compatible way as usual so we don't > break anything) Just keep it, what's wrong with it? > 8) Consider whether people are ready to stomach the phasing out of /dev/vg/lv > or whether that should move to /dev/lvm/vg/lv so it doesn't pollute the > flat /dev namespace. (LVM2 has always worked with just vg/lv and simply > treats '/dev/' as an optional prefix, not a path.) > > 9) Also consider whether there's a better prefix than dm- to use on these > devices. It's too easily confused with md. map- perhaps. Other ideas? I think it's fine as it is. I think the easiest solution is just to keep the dm-* names as they are, and create proper symlinks in /dev/mapper/, which would be the first time for DM /dev names to be reliable, and people could just use them. I'm not convinced at all, that you guys need to invent anything new here, before you have your stuff reliably working on a modern hotplug system. And fancy renaming infrastructure is nothing anybody ever asked for. People want reliable multi-device auto-assembly, device auto-setup, and proper hooks to plug into the processing. The last thing we need here is some new special cases for DM, which do not fit into what all others are doing. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
