Are there alternatives to using `udev`?

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

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.

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