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
