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

[Lennart Poettering]

On Thu, 18.09.14 21:21, Emil Renner Berthing (systemd at esmil.dk) wrote:

> Hi Tom,
> 
> 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.

Well, "bloat" is a misleading term here. canonicalize_file_name() you
can implement via a macro hence costs pretty much nothing. And
parse_printf_format() is genuinely useful, that's why we make use of
it. It's also something that can only be reasonably implemented at the
same place your printf() implementaton is maintained, since it needs
to stay compatible with that.

In general I think it's a very weird approach to have a non-useful
libc and then claim things would be less bloated because every user of
a variety of useful GNU APIs is supposed to reimplement everything
from scracth, so that we have a multitude of different, crappy
implementations in a variety of projects, instead of a single one in
the libc. Your overall footprint will be larger. 

Also, the entire dance around "POSIX is awesome and what we thrive
for, and GNU is bad" is just nonsense. It shows that your libc was
created for religious reasons, not for practical ones. If you want to
create something useful, create something useful, but don't cut off
useful functionality people use just because it was introduced by GNU,
not by POSIX. The POSIX API alone does not cover many many things
anyway. POSIX doesn't know epoll, pivot_root(), memfd, fanotify,
inotify and all those other Linux-specific syscalls, that solve real
problems. Don't tell me musl refuses to support those too? Or is Linux
good, just GNU bad, hence Linux extensions are well supported, just
not the ones from GNU?

We will not take part in this game. Yes, we tend to gravitate more
towards POSIX interfaces, if both a GNU and a POSIX version exists and
both are equivalent in their functionality. But also: we will make use
of GNU extensions and of Linux extensions if they are useful. And
since these ultimately are part of the Linux API, that is the right
thing to do.

Anyway, regardless what the goal of the patches people sent us are and
whether we sympasize with them, we'll always merge the ones that make
sense to us. We are not married to GNU, but we are married to the idea
that we will rely on good APIs exposed in the generally accepted Linux
API which is the one glibc exposes.

Hope that makes sense,

Lennart

-- 
Lennart Poettering, Red Hat