Are there alternatives to using `udev`?

Question

While I understand the greatness of udev and appreciate the developers' effort, I was simply wondering if there is an alternative to it.

For instance, I might imagine there should be a way to make startup script that creates most of the device nodes which on my system (no changing hardware) are most the same anyway.

The benefit or reason I would like to skip udev would be the same as for skipping dbus, namely reducing complexity and by that increasing my changes to setup the system more safely.

Solution 1

There are various alternatives to udev out there. Seemingly Gentoo can use something called mdev. Another option would be to attempt to use udev's predecessor devfsd. Finally, you can always create all the device files you need with mknod.

Note that with the latter there is no need to create everything at boot time since the nodes can be created on disk and not in a temporary file system as with the other options. Of course, you lose the flexibility of having dynamically created device files when new hardware is plugged in (eg a USB stick). I believe the standard approach in this era was to have every device file you could reasonably need already created under /dev (ie a lot of device files).

Of course the difficultly in getting any of these approaches to work in a modern distro is probably quite high. The Gentoo wiki mentions difficulties in getting mdev to work with a desktop environment (let alone outside of Gentoo). The last devfsd release was 2002, I have no idea if it will even work at all with modern kernels. Creating the nodes manually is probably the most viable approach, but even disabling udev could be a challenge, particularly in distos using systemd (udev is now part of systemd, which suggests a strong dependency).

My advice is stick with udev ;)

Solution 2

Modern Linux kernels support the devtmpfs file system ^{(do not confuse with ancient devfs)}, which creates all device nodes dynamically as soon as the kernel discovers them. (In fact, latest udev releases require this; you'll find that udev doesn't create any device nodes anymore, only symlinks.)

Similarly, firmware loading has been moved into the kernel as well, so the only remaining tasks udev performs are module loading (according to modaliases) and applying of device permissions & other udev rules.

So in theory a fully-monolithic kernel should boot just fine without udev.

However, the real problem here is what happens later.

1. Quite a few userspace programs rely on udev maintaining its device database, accessible through libudev. While enumerating devices and listening to added/removed events could be done directly using the kernel interfaces (sysfs and netlink), you'll still be left without all the metadata that various udev rules have attached.

2. udev rules also maintain various "persistent" symlinks in /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-path, and so on. For example, if you have two disks connected, there's no guarantee that the first one will always be sda or sdb, but udev ensures that the symlinks in /dev/disk/by-uuid will continue to point to the right one.

3. While device nodes are now created by the kernel and therefore not your concern anymore, it is still important to note that some device types have started using dynamically assigned major/minor numbers, so even though you have /dev/fuse as 10,228 and /dev/hpet as 10,229 today, they will have different numbers after every reboot, so either devtmpfs or (on older systems) a program that listens to uevents is required.

Many of these things could easily be done by other programs such as mdev, of course. My point is that a static /etc/MAKEDEV script isn't going to work anymore...

---

So, basically, when it comes to boot complexity, udev is quite likely the least of your concerns.

Solution 3

There are several alternatives:

• Simply have a set of appropriate chmod, chown, ln, and suchlike commands in a script that is run as part of the bootstrap.
• Use systemd-udev, the plug-and-play manager that is part of the systemd project.
• Use Gentoo's eudev, which is a fork of systemd-udev from which systemd has now significantly diverged.
• Use Devuan's vdev, which is a plug-and-play manager developed by Jude Nelson, that is part of Devuan.
• Use mdev, which contrary to another answer isn't a Gentoo thing. It's the plug-and-play manager that is built into BusyBox.
• Use Suckless mdev which is a plug-and-play manager developed by Dimitris Papastamos.
• Use Laurent Bercot's mdevd, which is configuration compatible with BusyBox's mdev but does its own socket handling and does not understand the LISTEN protocol.

All of these, apart from the first, require sets of rules describing how to react to kernel notification events about devices. Obviously.

There are also tools that will take programs designed for /proc/sys/kernel/hotplug, such as the two mdevs, and that will adapt and serialize them by listening to a netlink socket and then spawning those programs:

• Laurent Bercot's old s6-netlink-listener and s6-uevent-spawner
• netlink-datagram-socket-listen and plug-and-play-event-handler from the nosh toolset

Solution 4

udev? The best alternative is not to use it. And by learning how to not use it Linux and the *NIX world will begin to make more logical sense.

The best long-term alternative is to use static devices (see note). If you've got the driver, the Linux kernel manages hot-plugging. I prefer not having udevd running, ever.

dbus is another matter. It does slow down your system but, the ever-changing world of script folks love it. So, a lot of things, you're used to, like web-browsers or applications with script-backends, have to be fixed (launched or rebuilt without that stuff or dumped for another application).

Note: If you're just plugging in a flash drive or dvd device, use dmesg|tail to see the name of the device to mount. Learning when a device is a character or block device is fundamental system knowledge in the world of computer hardware. In Linux it's open source, check this out a lot about Linux, not just embedded. It's the best for a broader understanding the straight forward logic (not philosophy) of all *NIXs, like Linux (Solaris, HPUX, AIX, etc).

Udev, dbus, gconf/dconf, systemd, gnome-shell, Gnome, Glib, mono and Fedora are for people with loads of time on their hands who can't RTFM, or wanting an automatically updated really slick (looking) but, slower than molasses, buggy, half-way-there Linux. (A truly awful place, look around the web for tons of similar experiences).

The system boots then runs udevd. But, it's claimed udev is necessary because, device minor numbers will change on reboot. Udev's raison d'etre seems to contradict itself at every turn. And where it's files are seems always wrong no matter who you consult. Don't trust or freedesktop.org.

Besides udev is being absorbed into that horror known as systemd, I don't know what one does with ones /etc/udev junk then. And, it is fatuous to say that writing udev rules is somehow better than anything. The gentoo folks seem to want to hang onto it and not have to have systemd, so they've forked it to eudev.

If you want a ridiculously fast, no nasty suprises system, use the Linux basics.

View more solutions

Comments

[humanityANDpeace]

Thanks! Great answer which addressed most if not all of aspects of the question and was full of information! Wonder how to solve the systemd problem now... I will see how to disentangle this :)

[Elias Probst]

udev should work perfectly fine without systemd - they both are just developed within the same code-base, but udev can be built + run independent from it.

[Graeme]

@Elias, of course, udev has been around far longer than systemd anyway. The question is, can systemd work without udev? My guess is that you would at least have to recompile with some kind of --without-udev option.

[Graeme]

Interesting, do you know which kernel version introduces the dynamic creation of nodes?

[humanityANDpeace]

@grawity Fair point, but maybe I am not even that fine with booting with systemd for init then! gotta give it a look

[jasonwryan]

This is more of a rant than an answer...

[humanityANDpeace]

@jasonwryan somewhat yes, still there is some value since it advices some ways to manually deal with those tasks normaly covered in the udev functionality. It is somewhat also ok to point out the strengthes of this alternative approach.

[Victor - Reinstate Monica]

Upvoted this. The rationale being while I completely agree that the style might be considered inappropriate by some, it has its merits, and even if it is not actually helpful, I am tending to accept it as factual. In kernel 4.x, udev is randomly renaming ethernet interfaces.. WHAT?!

[Emmanuel]

You can't rely on kernel for devices persistent naming. At least udev gives you the control of it.

[colin]

Lol, such a get off my lawn answer.

[neoedmund]

Is there a script to load all the kernel modules can be loaded if not blacklisted?