What's the purpose of udevd? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The answer is surprisingly not simple. Current kernels run with devtmpfs, create device nodes themselves, and load firmware without userspace helpers. That's the bulk of what a userspace device daemon is supposed to do. Another issue is that udev is generally assumed to be a single tool to manage all kinds of devices. Current Linux environment seems to favor separate tools handling specific device classes, one for block devices, another one for inputs and so on, all listening to udev events at some point but doing wildly different things otherwise. It is not clear yet if there's any reason to have some sort of "udev" in minibase, and what kind of tool it should be. The following text outlines some thoughts on the possible tasks for such a tool. Watching for new devices ~~~~~~~~~~~~~~~~~~~~~~~~ Some applications may want to pick up new devices immediately as they appear. Common examples: keymon and display managers are expected to pick up new inputs immediately without an explicit command to do so. In mainline udevd-based (and later systemd-based) setups the application are expected to listen to udev events to figure out when a device gets added to the system, and make their decisions based on the contents of udev message and the stuff in /sys. Note the above does not involve udevd in any form. The application only needs to listen to the (kernel-generated) udev events. In fact, trying to stick udevd in immediately leads to synchronization issues, as the application may pick up the device before udevd has a chance to do its thing. Applications may avoid udev altogether by using inotify on /dev. Sane device naming scheme ~~~~~~~~~~~~~~~~~~~~~~~~~ In current Linux device names are unreliable and often meaningless. One has to sift through /sys or even probe the device to figure out what exactly say /dev/input/event19 refers to. An application watching for new keyboards will have to open the device just to figure out it's not a keyboard at all, and close it (if possible that is, note that weston-launch protocol lacks "close" command and there are good reasons for that). It would be better to name devices in meaningful name, say /dev/input/ptr-stick instead of nondescript /dev/input/event19, and /dev/input/keyboard instead of /dev/input/event0. This way, the naming and identification of devices could be left to udevd, and the applications could then rely solely on device names to decide whether to pick them or not. Implementing this idea well seems to be *impossible* in Linux. There are essentially two way to do it: renaming the devices when they appear in /dev, and symlinking reliable names to kernel-generated unreliable ones. Renaming breaks both /dev <-> /sys relation (because /sys nodes will keep their kernel names) and devtmpfs ability to unlink removed devices. Symlinking is ugly in itself, and requires very ugly code to remove symlinks when the device gets removed. At this moment, the decision is to stick with the kernel names and use /sys if necessary for device identification. User-accessible devices ~~~~~~~~~~~~~~~~~~~~~~~ Some devices should be left fully accessible for non-privileged users of the system. One particular case is ALSA devices, unless some sort of audio service is used that accepts non-privileged connections and forwards the data to the devices. It is not clear whether such a service is really necessary. Without a dedicated audio service, this clearly calls for udevd capable of chmod'ing and/or chown'ing device nodes meeting certain criteria. Devices requiring initialization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some printers need their firmware uploaded on startup with userspace tools. Now this is clearly not how firmware loading is supposed to work in Linux, and devices that need this are really rare. Not clear how to handle it yet. Udevd capable of running arbitrary commands when certain device appears could be a solution. Containers and multiseat configurations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Likely requires a dedicated tool, not a general-purpose udevd.