t.j.duch...@gmail.com: > From: Hendrik Boom > Sent: Wednesday, December 31, 2014 8:44 AM > > > Never mind the mechanisms for now. > > May I ask what all this complexity is supposed to accomplish?
(please don't top post) > The reasons for a dynamic device manger were simple: > > a) Actually makes sure that the device really exists, and is > connected rather than having a static /dev entry that is > essentially worthless. Isn't that a thing for the local administrator to decide upon ? Don't force people. I've been bitten by not having an /dev entry even though the device was there. Udev done me disservice more than once. > b) A dynamic manager provides a consistent way for naming device > nodes, rather than having administrators create nodes willy-nilly. If I "willy-nilly" create devices then I don't want some daemon to change that, and I don't appreciate the need to relearn things just because 90% of the others found out a new way of doing things. > c) Provides a persistent API for managing the devices programmically, > so that you can add device capabilities to your user programs in a > consistent fashion. There is an api for "managing" devices: open/close/read/write/ioctl/..., mount, umount, etc. But I suspect you are aiming for something else. From the little I know about libudev, there is the ability to map major/minor to /dev/-name. Something else ? > That’s more than enough reason to not go back to the old way of > doing things, although it should be noted that you can create a > system library to manage static nodes in a similar fashion. Some people are not "going back", they just don't embrace every new thing; they just stay on firm ground. > Most of the reasoning behind the most used managers is to allow > “hotswapping” without manually mounting > I don’t have a problem with this, as long as the security > implications are considered in advance. That ortogonal to having *dev managing /dev, and if desktop users wants their usb-disks to be automatically mounted, let them, but don't force me. If I unplug the one and only disk on the system (/dev/sda), no amount of udev trickery will help my system from crasching, since the kernel will assign it a new major/minor number - the current one is locked by the root file system. It does not matter at all whatever name it has in /dev, since it won't be the same device in the kernels view, and all commands you try to use to remedy the situation with will segfault unless they are already in memory. You could do that with the old /dev/hda, because the kernel assigned the disk the same major/minor number each and every time you attaced the drive in the same place (same cable, same connector, same strappings). What you name things in /dev, is just a convenience, what really matters is what major/minor number you come up with in the end. So, what's all the fuss whith what name there is in /dev/, let each and every user *be able* to decide for themselves. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
