Auteur: BRM Date: À: karl@aspodata.se, dng@lists.dyne.org Sujet: Re: [Dng] Purpose of all this complicated device management?
> On Saturday, January 17, 2015 12:49 PM, "karl@???" <karl@???> wrote:
> t.j.duchene@???:
> > From: Hendrik Boom
> > Sent: Wednesday, December 31, 2014 8:44 AM
> > 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.
The default udev rules (more below) provide the same functionality as the original behavior.Except in some cases where some distros (and this was a systemd thing early on IIRC) decided to start renaming things in odd-ball ways like the old Unix systems did.They seem to have forgotten that many of us found the old Unix naming system to be a very poor system.For instance /dev/eth0 is much better than /dev/e1000g0 (Solaris).
> I've been bitten by not having an /dev entry even though the > device was there. Udev done me disservice more than once.
Me too, until I figured out the udev rule system.
> > 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.
So the issue doesn't simply become it's a willy-nilly thing, but rather if you want to be able to do anything with USB, Firewire, Thunderbolt, etc you kind of have to have a dynamic allocation support for stuff. > > 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 ?
Stop right here and go learn more about udev.The biggest thing to learn about udev is the udev rules which control how things are named. > > 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.
Using udev you can keep what you want...
> > 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.
udev has nothing to do with auto-mounting. It only has to do with device naming.Automounting is left to other layers, previously hald which seems to have moved to udisks. > 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.
This is what udev rules are for. You can name devices however you want.If you want to name your eth0 to "/dev/alice" or "/dev/bob" you can; just update the udev rules.You can match against things like the PCI slot, device id, mac address, serial number, and other stuff - some of which is specific to the device.That is, with udev if you want your hard drive with serial number XYZ to be /dev/hda no matter what, you can make that happen.So even if that drive isn't connected, you can make it so that udev won't use /dev/hda except for that one device.
So please, go learn about udev rules.