[systemd-devel] [RFC 00/25] Compile against the musl libc

[Tom Gundersen]

On Thu, Sep 18, 2014 at 9:21 PM, Emil Renner Berthing <systemd at esmil.dk> wrote:
> On 18 September 2014 18:29, Tom Gundersen <teg at jklm.no> wrote:
>> In general, I don't think we should add patches for the sole purpose
>> of non-glibc compatibility. You would in most cases be much better
>> served by adding the missing functionality to your libc, rather than
>> to each of the project requiring the functionality.
>
> Thank you for looking through these. The problem is that musl is aiming
> at making a lean and efficient posix libc, not a glibc clone. So stuff
> like parse_printf_format and canonicalize_file_name is not a fix, but
> unnecessary bloat. So it seems I'm stuck between a rock and a hard place.
> I guess I had hoped the resistance in this camp would be more against
> doing the work rather than actually be able to work with a posix libc and not
> only glibc.

We are not against being more POSIX compliant per se, but
reimplementing functionality in systemd that arguably should be done
in libc does not make much sense to me. If parse_printf_format (for
instance) is too bloated for yor libc, then surely putting it in
systemd gives the same amount of bloat overall (actually, it would be
worse as it would probably get statically linked into most of the
systemd-* binaries, whereas if you keep it in your libc it would only
be around once, and if you have more than just systemd around that
requires the functions to be reimplemented it gets worse still). Using
a minimal libc may make sense with projects that explicitly only use
minimal functionality (without reimplementing things), but avoiding
useful features is not a game systemd wants to be in, so I don't think
that applies here.

I understand not wanting to include unused functionality in libc if
you are trying to save space, but by not including stuff that is
actually used on your system I don't see how you gain anything.

I would rather try to compile glibc and systemd with unused
functionality disabled, or perhaps add the missing functionality to
your libc and make it optional for systems that don't require it.

>> That said, we are of course happy to take patches that are "the right
>> thing to do" regardless of which libc is being used, so I merged some
>> of the patches you posted.
>
> Cool. I can resend updates of the ones you commented on.
>
>> Btw, have you considered simply putting glibc on your router in the
>> first place? If you can fit systemd, you can probably fit glibc too...
>
> Well, last time I tried this linux, musl, systemd, busybox, base, I had a
> Lua webserver running from linux + squashfs taking around 3MB out
> the 8MB available on the gadget. Maybe systemd has grown since then,
> I didn't get this far this time around.
>
> Also I think I might have made a mistake in mentioning OpenWRT. My
> point was more that I'd like systemd to run on hardware with the same
> kind of specs as OpenWRT is designed for, not necessarely replacing
> OpenWRT everywhere. I was thinking of gadgets like the VoCore [1],
> Arduino's Yun [2], Intel's Galileo boards[3] and Edison SOC [4] to name
> a few.

Would be cool if you get this working. Good luck!

Cheers,

Tom

> [1] https://www.indiegogo.com/projects/vocore-a-coin-sized-linux-computer-with-wifi
> [2] http://arduino.cc/en/Main/ArduinoBoardYun
> [3] http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html
> [4] http://www.youtube.com/watch?v=GY8kaaFzbTE