t.j.duchene@???:
> 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