Quoting Laurent Bercot (2024-05-26 12:53:39)
> If you are building a distribution aimed at supporting several kinds
> of hardware, I suggest adding flexibility at the *source database*
> level, and building the compiled database at system configuration time
If at all possible, do this.
> (or, in extreme cases, at boot time, though I do not recommend that if
> you can avoid it, since you lose the static bootability guarantee).
I believe there is also a third approach which is sort of a middle-ground: all
oneshots and longruns are compiled statically, but the contents of bundles are
determined at boot time. Think of it by analogy to the Linux kernel: distros
nowadays build every single module under the sun -- no matter how obscure -- but
only a few ever get loaded.
I believe that s6-rc-bundle is the tool used to edit the bundles:
https://www.skarnet.org/software/s6-rc/s6-rc-bundle.html
I haven't actually tried this myself, but perhaps it might help. Changing the
contents of bundles seems like a much less-violent action to take at boot time,
with fewer possible failure modes.
If you go this route, there is a fork in the road. Assuming you're using
s6-linux-init,
- The easy route: in a perfect world you'd do this boot-time detection from
within `rc.init`, before invoking `s6-rc start $DEFAULT_BUNDLE`.
Unfortunately at that point you probably don't have anything mounted
read-write (except /run), haven't started your hotplug daemon (e.g. mdevd),
and haven't done a coldplug yet. So the easy route might not work.
- The hard route: remember that s6-rc's locks are *not* reentrant! You will
have to think very carefully about what locks are held with s6-rc-bundle is
called, and whether or not to use its `-b` flag. Don't try to use s6-rc tools
from within a oneshot.
- a
Received on Tue May 28 2024 - 07:36:38 CEST