Re: mdevd / udevd issues, and the issue of "reverse" dependencies

["Laurent Bercot" <ska-supervision@skarnet.org>]

>This has obvious benefits, at least for now.  udevd does not have
>a readiness notification mechanism (polling for the existence of
>/run/udev/control surely does not count)

There is no fundamental reason why it doesn't. inotify works on tmpfs;
you don't need to poll for the existence of /run/udev/control, you can
inotifywait for its appearance.


>  and s6's fd-based mechanism does not integrate well with the shell

That is true, but I shamelessly chalk that up to the shell's
limitations: the shell can't create anonymous pipes outside of a
pipeline, and it can't make a pipeline without forking both the reader
and the writer. It's a terrible tool when you need semi-serious
plumbing work.


>  (Another issue, currently unsolved,
>is that mdevd does not have a "udevadm settle" equivalent, so that in
>theory we are not sure the basic devices are fully coldplugged when
>`mdevd-coldplug' exits.)

Funny you should mention that, it's the very problem I've been hitting
last week :)

It would be quite difficult to add a "udevadm settle" to mdevd. It
would require a communication channel with the outside (a fifodir?), and
heuristics to guesstimate when the coldplug starts and when it stops,
which I'm not sure could be made reliable in all cases. To be fully
reliable, the mechanism would need synchronization with the coldplugger,
and at this point we're well on our way to duplicating the bloat of
udevd.

However, depending on the kind of device you're waiting for, it may be
possible to avoid the race for that device. I needed to wait for a
network interface to appear after the coldplug, so I wrote a tool that
does just that: bcnm-waitif, in the bcnm package. (Documentation coming
soon.) So at least network interfaces are covered now.


>In the above, you have seen that I switched from `devd' depending on
>`devices' to the converse.  Suppose the problem of handling readiness in
>the shell could be done in a "magically simple" way, I would personally
>prefer the original way.

I don't understand why you'd prefer the original way. The natural and
normal way of proceeding is 1. start the daemon that processes the
uevents, 2. trigger the initial hardware scan that produces a big
batch of uevents. You don't need a temporary devd when you can just
start the real one; if the interfaces around the existing devd
implementations make it difficult to start properly, that's what should
be fixed.

--
Laurent