>Look, here's a trivial, suboptimal wrapper, far from pretty:
> (...)
>(look, I said it wasn't pretty -- there are at least a dozen of problems
>with this, but nothing a day of work I offered to do can't fix; I wrote
>this because it was faster than talking without a concrete example to
>have some figures, and that took me less time than the rest of this mail)
Damn you to the nine circles of Hell, one by one, slowly, then all of
them at the same time.
You piqued my curiosity, so I did it, and I spent the day making it
work.
The execline git now has a 'multicall' make target. It will make an
"execline" binary that has *everything* in it. You can symlink it to
the name of an execline program and it will do what you expect. You can
also call the subcommand as argv[1]: "execline exit 3" will exit 3.
No install targets, no automatic stripping, no symlinks, nothing.
I don't want to officially support this configuration, because I *know*
it will be a time sink - every ricer on the planet will want me to
change
something. So you get the binary for your own enjoyment, and that's it.
Have fun. If it breaks, you get to keep both pieces.
It's really rough: it only marginally improves on your model, fixing
the most glaring problems. The only fancy thing it does is find the
applet via bsearch(), because that's easy and it saves about 20 strcmp()
per call. Apart from that, it's super dumb.
That said, you were right: that's some pretty hefty saving of disk
space. The execline binary is 169kB, statically linked against musl on
x86_64. That's neat. I expected it to be at least twice bigger. And
the data/bss isn't too bad either: only 2 pages. But that's because
execline programs use very little global memory in the first place -
the only places where globals are used is when state needs to be
accessed by signal handlers, and there's nothing I can do about that in
short-lived programs. (Long-lived programs use a selfpipe, so only
one int of global data is ever needed for them.)
So, all in all, much better results than I expected, it was a pleasant
surprise. Still, concatenating all the code feels really clunky, and
a real multicall program needs to be designed for this from the start,
which won't happen for execline in the foreseeable future, so this is
as much as you get for now.
If you're interested in hacking the thing, the magic happens in
tools/gen-multicall.sh.
> libexecline is statically linked, so these pages aren't shared afaik?
That's right, I forgot it was always statically linked. If it helps,
changing ${LIBEXECLINE} to -lexecline in the src/execline/deps-exe
files, then running ./tools/gen-deps.sh > package/deps.mak, should
allow you to link against a dynamic libexecline. Can you do it, see
how much space you gain? That's a configuration I would definitely
support, even if it's slower - people usually love shared libraries.
>I really don't see what's different between e.g. execline and coreutils,
>who apparently thought it was worth it;
coreutils also thought it was worth it to implement true --help and
true --version, so I'll leave to your imagination how much I value their
technical judgment.
The only way to know for sure whether it will be worth it is to stop
speculating and start profiling, which is what I did. And it appears
the results are interesting, so, that's great!
Sigh. I shouldn't feel that way, and any potential improvement should
be a source of joy, not dread - but really I wish the results weren't
so good. Now Pandora's box has been opened and everyone will want to
use the multicall exclusively, so at some point I'll have to support it,
i.e. ensure it's actually correct and enhance its maintainability.
And that means a lot more work. :(
>But, unfortunately for you, the full openrc suite is 2.2MB (5 on arm
>with bloated aarch64), which is a bit less than the s6 suite :-D
No, that's fair. It's true that s6 takes a bit more disk space.
Where OpenRC loses is RAM and CPU, because it does everything in
shell scripts. And shell scripts definitely win on disk space. :)
--
Laurent
Received on Wed Feb 01 2023 - 19:59:04 CET