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
Received on Mon Feb 10 2020 - 17:19:43 UTC