[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210820202940.GQ13220@brightrain.aerifal.cx>
Date: Fri, 20 Aug 2021 16:29:41 -0400
From: Rich Felker <dalias@...c.org>
To: Olivier Galibert <galibert@...ox.com>
Cc: musl@...ts.openwall.com
Subject: Re: Is systemd in scope for musl?
On Fri, Aug 20, 2021 at 08:55:43PM +0200, Olivier Galibert wrote:
> Hi,
>
> I'm trying to build a kinda-distribution of linux on arm64 where all the
> userspace is done with clang and which uses systemd[1]. I can either use
> glibc or musl. Glibc aggressively does not want to be compiled by anything
> else than gcc. Musl is missing a bunch of stuff systemd wants.
>
> I have two possibilities, either make glibc work but not contribute the
> changes (because I don't want to give my copyright to the fsf[2]) or extend
> musl until it has all the missing APIs and contribute them. I'd rather do
> the latter.
systemd support is out of scope because systemd has no contract for
what they will use except "anything in glibc we like". We are not
going to get in the business of letting systemd dictate what goes in
musl, and are not going to start adding functions now that just happen
to make the current version of systemd build, because they will never
be enough and folks will just complain again when it breaks, and we'll
be stuck maintaining the junk functions we added already. This has
been discussed in at least one thread in the past.
On the other hand, many people have successfully used systemd with
musl just by patching it not to use glibcisms. I believe
yocto/openembedded maintains patches for this.
> Some APIs (qsort_r) are clearly going to be added in the future. Others
> are very glibc, e.g. printf configurability stuff, and do not come from any
> standard. So, is "this API is used by systemd" a good enough reason to
> accept it as in-scope for musl[3] or will there be things that are "never"
> going to be accepted?
The criteria for inclusion/exclusion of nonstandard interfaces involve
multiple factors including existing precedent across multiple systems,
how widely used it is in applications, whether there's justifiable
reason applications need it vs existing portable interfaces, size of
code, interactions with other libc components that constrain their
implementations, etc.
The printf customization stuff is a huge no in that last area,
introducing mutable global state where there was none and being
library-unsafe (impossible for different independent parts of the
application to each use without stepping on each other). Some of the
other things systemd wants aren't "hard" no's, but simply have nothing
significant using them except systemd, which is apparently using them
for the sake of being stubborn, and lots of individual soft reasons to
lean towards no.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
