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

["Casper Ti. Vector" <caspervector@gmail.com>]

I recently added service definitions for mdevd into slew, during which
I switched from a `devd' longrun (which has a dedicated logger, and so
requires a R/W filesystem) that depends on a `devices' oneshot (starting
a temporary devd process to coldplug basic devices) plus a `devd'
longrun to a single `devd' longrun (which starts early, and just logs to
the catch-all logger) followed by a `devices' oneshot (which just do the
coldplug).

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), and s6's fd-based mechanism
does not integrate well with the shell (at least I have not come up
with a way that avoids the hassle of setting up a temporary fifo and
dancing with foreground and "background" processes that play with the
fifo).  So the `devices' oneshot is destined to be complex if "up" is
not to be identified with "ready".  (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.)

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.  However, I would like the switch between mdev,
mdevd, udev etc to be painless, so `devd' is not necessarily present;
instead, I want `devices.mdevd' / `devices.udevd' to automatically drag
`devd' into the dependency tree, even if it is `devd' that depends on
`devices' instead of the converse.  This request is admittedly based on
a fictional premise, but the supposed relation between `devices' and
`devd' is similar to that between `wpa_supplicant' and `wpa_cli', and
the latter is not fictional.

I do not find this kind of "reverse" dependencies trivially doable in
preprocessors (like slew's `prep').  The strightforward way to make
service `srv1' reverse-depend on `srv2' is to create a bundle that
contains both `srv1' and `srv2', and then to make all that depend
on `srv1' actually depend on the bundle; but how should we name the
services?  To minimise rewriting of config files, we would naturally
considering renaming the original `srv1' to something else and let the
bundle take the name.  However, the scripts in the original `srv1' may
change its behaviour based on the service name (eg. `getty.tty1' and
`dhcpc.eth0'), so some careful planning are needed to prevent the
renaming procedure from crashing with this mechanism.

Any thoughts on these issues?  Thank you in advance.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C