On Wed, Apr 29, 2009 at 13:52, Milan Broz <mbroz@xxxxxxxxxx> wrote: > Kay Sievers wrote: >> On Wed, Apr 29, 2009 at 04:45, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: >>>> Also DM allows pretty stupid free-text device names, and names >>> We took the view there was no need for any restrictions beyond >>> '/' in the kernel and it was a matter for userspace to choose >>> the namespace. >> >> And these days are over. /dev is not the thing anymore where everybody >> can mess around. > > We had problems with some multipath vendors which named storage device > paths using strange names/chars (according to LUN name, from hw). > > Also dmraid sets uses names collected from proprietary metadata. > > Change this means change to several tools. And there are probably still > reasons to name devices according to hw provided names. > > So if there is name limitation, we need to create some mapping which > is acceptable both for udev and administrators/users... Sure. But there is a general rule, that the kernel does not take any device names from untrusted sources, which includes in this case un-mangled hardware strings. There is a reason, that every subsytem in the kernel uses a basename string and an appends an enumeration number. People can do all crazy names as symlinks in /dev, but not as device node names, or kernel device names. >> Sure rename them. But if you want the device node renamed, rename the >> kernel devices too. > > Sure, but it will have consequences which must be solved too. > > E.g. the dm uuid can be max. 128 characters, I am sure that we can use that > in kernel for internal device name. > (uuid is not just plain UUID string, it includes prefix of subsystem, > like LVM- MPATH- etc.) > > But how many userspace tools expects such long name in /sys/block? I don't know. I'm not saying that this is how DM should do it. I'm just saying that the kernel block device name and the primary device node must always match. And that a kernel device name can not really change during the lifetime of device, unless you want to go through a real pain managing userspace here. Even then, there can be no disconnect between the kernel name and the node name. Here again, we have the working concept of simple enumerated kernel names, and meaningful symlinks to a node with the same name, and I absolutely fail why dm wants to be special here. It is like this for everything on a hotplug system. The current nodes in /dev/mapper just don't work at all. Some distros, who care about dynamic device management, even replaced them already with symlinks today. > People are using udev but also lvm, dmaid, multipath, kpartx, cryptsetup, etc. > > We need to find some way how to fix that and not break these systems. Sounds good. But the previous emails suggest something totally different, they even mention to change every name we have today. > Maybe the symlink to /dev/dm-X is first step. This will switch dm to using udev, > what is the primary goal now, thought. That's what I think it is. > and (later?), Well, add more links, as many as you like, there is no real limit. :) > - introduce mandatory uuid for dm device (or disable rename for devices which > have no uuid set and keep the old dm-X name for them?). Sounds nice to me. > - use dm uuid, so the internal kernel device name will be persistent > (and avoid dm-X where X is dynamically allocated number) > (I think udev rules should be still the same here if written properly.) That could work, yes. > This requires kernel changes outside DM, like remove device name limit > in partitioning code. Which is a good thing to do, yes. > - fix tools to "understand" the new names > * long name in /sys limitation That should be easy to fix, and also worth to do, not only for dm. > * fix mapping of not udev-valid characters We just need to prevent people from adding names like "dm-`rm -rf /`", because some links in /dev are created from pretty much untrusted sources. > * probably some tweaks for tools which sometimes prefer > to display symlinks instead of kernel name (if symlink exists) They should probably just show all currently known names, if asked for. There is never only a single name for a device, besides maybe the uuid can be seen as one sometimes. Many other names are only valid at a certain point in time, or identify multiple devices at the same time. > (I mean e.g. lvm user expect device like /dev/VG/LV1 (symlink) for PV report > and not /dev/dm-LVM-0124-9438-1238-8129. > If there is way to avoid these tweaks and keep /dev/<internal kernel name> > then of course use that:-) > (I mean tools like blkid & Co.) Sure, sounds good. > Please also note that clustered LVM can complicate things, the device > name (created node in dev) must be the same on all nodes in cluster etc. Oh, "it's just the device number that is important", "users have to cope with that" was an earlier statement in this thread. :) > I feel that this discussion heads to flame who is dreaming and slept last > years... please, no:-) Well, I'm looking for _integration_ and not for more hacks. I also don't look for new features in an almost completely broken subsystem regarding hotplug setups. This is about making the current stuff work, and not to introduce new features, or changes nobody needs at this moment. Don't take that personally please, I'm just a bit annoyed by the stuff that is brought up here now, and all the words spoken, with no action taken, during the last five years. I absolutely appreciate the effort, to change things now, and I'm happy that it looks like this time is something happen for real, but I also completely disagree with parts of the proposals made here. And I seriously ask you guys to work on _integration_ and _fixes_, and not on new features or new names in /dev, or whatever else which just make things even more complicated as they already are. And integration means, that the kernel device name, and the kernel error log, and the /dev nodes match. That's how Linux works today. And meaningful device names, which can be many, and which can change during the device lifetime, are done by symlinks, and not by renaming device nodes. Thanks, and sorry, 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
