devfs is not gone [LWN.net]

devfs is not gone

Posted Nov 18, 2014 0:23 UTC (Tue) by nix (subscriber, #2304)
In reply to: devfs is not gone by zuki
Parent article: The Grumpy Editor's guide to surviving the systemd debate

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?

to post comments

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).