mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Is systemd in scope for musl?
@ 2021-08-20 18:55 Olivier Galibert
  2021-08-20 19:48 ` Max Rees
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Olivier Galibert @ 2021-08-20 18:55 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Is systemd in scope for musl?
  2021-08-20 18:55 [musl] Is systemd in scope for musl? Olivier Galibert
@ 2021-08-20 19:48 ` Max Rees
  2021-08-20 20:29 ` Rich Felker
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Max Rees @ 2021-08-20 19:48 UTC (permalink / raw)
  To: musl; +Cc: Olivier Galibert

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Is systemd in scope for musl?
  2021-08-20 18:55 [musl] Is systemd in scope for musl? Olivier Galibert
  2021-08-20 19:48 ` Max Rees
@ 2021-08-20 20:29 ` Rich Felker
  2021-08-20 21:44 ` Tim Tassonis
  2021-08-20 22:02 ` Ariadne Conill
  3 siblings, 0 replies; 5+ messages in thread
From: Rich Felker @ 2021-08-20 20:29 UTC (permalink / raw)
  To: Olivier Galibert; +Cc: 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Is systemd in scope for musl?
  2021-08-20 18:55 [musl] Is systemd in scope for musl? Olivier Galibert
  2021-08-20 19:48 ` Max Rees
  2021-08-20 20:29 ` Rich Felker
@ 2021-08-20 21:44 ` Tim Tassonis
  2021-08-20 22:02 ` Ariadne Conill
  3 siblings, 0 replies; 5+ messages in thread
From: Tim Tassonis @ 2021-08-20 21:44 UTC (permalink / raw)
  To: musl



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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Is systemd in scope for musl?
  2021-08-20 18:55 [musl] Is systemd in scope for musl? Olivier Galibert
                   ` (2 preceding siblings ...)
  2021-08-20 21:44 ` Tim Tassonis
@ 2021-08-20 22:02 ` Ariadne Conill
  3 siblings, 0 replies; 5+ messages in thread
From: Ariadne Conill @ 2021-08-20 22:02 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-20 22:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20 18:55 [musl] Is systemd in scope for musl? Olivier Galibert
2021-08-20 19:48 ` Max Rees
2021-08-20 20:29 ` Rich Felker
2021-08-20 21:44 ` Tim Tassonis
2021-08-20 22:02 ` Ariadne Conill

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git