[musl] Is systemd in scope for musl?

[musl] Is systemd in scope for musl?

[Olivier Galibert]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

  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.

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?

Best regards,

  OG.

[1] This list is not the place to bitch about systemd or my hobby choices
[2] This list is not the place to bitch about the FSF copyright policies
either
[3] Patches have to be good by themselves, of course

[-- Attachment #2: Type: text/html, Size: 1328 bytes --]

Re: [musl] Is systemd in scope for musl?

[Max Rees]

On 21-08-20 02:55 PM, Olivier Galibert wrote:
> 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 

Beginning last month glibc no longer requires copyright assignment to 
the FSF. You can just use DCO instead.

https://sourceware.org/pipermail/libc-alpha/2021-July/129577.html

Max

Re: [musl] Is systemd in scope for musl?

[Rich Felker]

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

Re: [musl] Is systemd in scope for musl?

[Tim Tassonis]

On 8/20/21 20:55, 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.
> 
> 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?


Without wanting to bitch about SystemD, their maintainer has repeatedly 
proven to not give one fuck about any standards or portability, he 
actually deliberately enforced non-portability to other libraries than 
glibc and kernels than Linux.

So, I doubt very much this is the way to go. Chasing a deliberately 
moving target is no fun.

Bye
Tim

Re: [musl] Is systemd in scope for musl?

[Ariadne Conill]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Hi,

On Fri, 20 Aug 2021, 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.

There is actually ongoing work in glibc to allow compilation with clang, 
and linking with lld.

> 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.

You no longer need to assign your copyright to the FSF to have code 
included in GCC or glibc since August 1.

> 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?

No, "this API is used by ________" is not sufficient scope for inclusion 
of functionality in musl.  The functions themselves must be justified on 
its own merit, e.g. with an example usecase highlighting why they are 
helpful.

Ariadne