>the solution here could be a simple symlink to the original s6 tool without
>the prefix if you prefer (maybe even located in an other dir than /bin).
That would be a decision for users, not software authors - else it would
defeat the point of not invading the namespace. Daemontools is still
around with names such as "svc".
>using a single combined tool is more efficient since it avoids wasteful further exec chaining steps, though.
Sure, but if we're talking about UI, optimization at this level is a
very
moot point. A human choosing between "chpst" and "s6-applyuidgid" will
*not* notice the extra millisecond taken by an execve() step. The
primary focus should be usability.
>Busy/ToyBox style ?
No, I don't like multicall binaries. I was more thinking of a wrapper
that rewrites its command line and execs into it, like s6-svc does when
given the -w option. The goal is simply to have a unified UI thing that
makes it easier for users to find the command they need.
>could you document the way s6-rc works (i. e. its architecture) somewhere ?
>or are users requested to follow your C code to find out how it works
>exactly ?
I am reluctant to make the ABI details public because I want the
freedom
to change them. If people start relying on internals, their stuff may
break when updating, which would be bad.
There are *some* details that I could document as official and stable,
but I'd need to go through all of it and decide with precision what can
be
guaranteed and what cannot - and that's extra work, so it will have to
wait.
--
Laurent
Received on Sat Nov 30 2019 - 18:58:14 UTC