devfs is not gone [LWN.net]

devfs is not gone

Posted Nov 13, 2014 22:29 UTC (Thu) by ebiederm (subscriber, #35028)
Parent article: The Grumpy Editor's guide to surviving the systemd debate

For some interesting reading go look in an old version of udev for it's why not devfs document, then compare that to what is delivered today with udev.

There has been a 100% back pedaling by the developers of udev. The only thing that has really been achieved is a less buggy implementation in the kernel.

Sadly device naming policy has for all practical purposes been removed from userspace.

Which is my long way of saying that I think it is a misrepresentation of the history of devfs and distributions to say that devfs has been removed.

to post comments

devfs is not gone

Posted Nov 14, 2014 3:34 UTC (Fri) by zuki (subscriber, #41808) [Link] (3 responses)

Do you mean docs/udev_vs_devfs?

It contained the following:

>The Problems:
> 1) A static /dev is unwieldy and big. It would be nice to only show
> the /dev entries for the devices we actually have running in the
> system.
Still there, check.

> 2) We are (well, were) running out of major and minor numbers for
> devices.
Check.

> 3) Users want a way to name devices in a persistent fashion (i.e. "This
> disk here, must _always_ be called "boot_disk" no matter where in
> the scsi tree I put it", or "This USB camera must always be called
> "camera" no matter if I have other USB scsi devices plugged in or
> not.")
Check.

> 4) Userspace programs want to know when devices are created or removed,
> and what /dev entry is associated with them.
Check.

>The constraints:
> 1) No policy in the kernel!
Check.

> 2) Follow standards (like the LSB)
Check.

> 3) must be small so embedded devices will use it.
I guess this is the most arguable point. udevd binary is now much bigger than the original 6kb, but it is still used in embedded, afaik.

I really don't see the backpedalling. If you look at the *implementation*, I'll grant that it has changed a lot. But the basic design, the division of responsibilities, and capabilities are there.

devfs is not gone

Posted Nov 18, 2014 0:23 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

The constraints:
1) No policy in the kernel!
Check.

That's not true. udev no longer creates /dev nodes, only symlinks to them: you must use devtmpfs, whereupon the kernel creates them. This is policy, in the kernel.

No coherent rationale that I can see was ever given for removing not only the requirement but even the possibility of creating /dev nodes from udev. Sure, on huge systems you want the kernel to do it, because it does it very fast -- but on normal systems, the extra flexibility seems worthwhile. It did save a few lines of code in udev, I suppose. Should that really be our priority?

devfs is not gone

Posted Nov 20, 2014 14:59 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

>That's not true. udev no longer creates /dev nodes, only symlinks to them: you must use devtmpfs, whereupon the kernel creates them. This is policy, in the kernel.

Well, I think that's a matter of interpretation.

Is the minor number of a device a policy question? I think most people would say no - it's a driver implementation detail and not intrinsically meaningful, nor something that you generally have to think about. So if we look at the scenario where udev creates all the device files, the naming and placement of those files is the policy, and the major/minor numbers used are not.

In contrast, we have the scenario where the kernel creates device files for everything it has, and udev creates links to them whose naming and placement conforms to (presumably) the same policy as in the first scenario.

These scenarios aren't really much different. In the first case, the major/minor numbers are some implementation detail that must be known by whatever process is deciding the policy, and are hidden from normal view. In the second case the non-normalised device files take the place of that implementation detail (well, add to it), with the only real difference being that in this case this implementation is more transparently exposed. Creating these device files is no more policy than the choice of major/minor numbers is.

I don't really see a compelling argument that either a) the details were better off left less visible, or b) the conceptual design is actually any different. It does add one extra layer of abstraction, but you seem to be saying that that extra layer actually enables the system to work *faster*, which is typically one of the big worries when adding yet another layer.

>but on normal systems, the extra flexibility seems worthwhile

What sort of things are you thinking of?

devfs is not gone

Posted Nov 20, 2014 16:11 UTC (Thu) by zuki (subscriber, #41808) [Link]

Yes.

Or to put it more succinctly, "sda" name is not matter of policy, but "MyFavoriteDrive" is, as are the by-uuid and by-path symlinks, ownership, permissions, and acls.

> No coherent rationale that I can see was ever given for removing not only
> the requirement but even the possibility of creating /dev nodes from
> udev. Sure, on huge systems you want the kernel to do it, because it does
> it very fast -- but on normal systems, the extra flexibility seems
> worthwhile.
The reason is consistency (we want the same capabilities and mechanisms on all systems) and simplicity (we don't want to carry an alternate implementation if the kernel already provides one) and a minimal increase in safety (if udev does not create nodes, it cannot screw them up).