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.


Reply via email to