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.