From: Adrian Bunk <bunk@stusta.de>
To: openembedded-core@lists.openembedded.org
Subject: Should systemd be marked as incompatible with musl?
Date: Thu, 23 May 2019 13:33:52 +0300 [thread overview]
Message-ID: <20190523103352.GA25084@localhost> (raw)
systemd is fundamentally Linux-only and not portable to other kernels.
systemd upstream is using glibc extensions not present in other
C libraries.
systemd upstream is accepting technically correct patches that help
building with musl, but there is no interest upstream in keeping systemd
working with non-glibc C libraries.
The way things currently go, systemd/musl will require an ever-growing
amount of not upstreamable patches - and this is not sustainable.
It is also not clear where the systemd/musl combination makes sense:
If an embedded system is so size limited that the size of glibc matters,
then systemd is unlikely to be an option.
Other musl-using distribution also seem to favour more lightweight
init systems.
If someone has important usecases for using systemd with musl it might
be possible to solve find solutions in an upstreamable way, but this
would require a significant longterm commitment.
The current state is rather bad, some examples:
0001-Use-getenv-when-secure-versions-are-not-available.patch
looks like waiting for a CVE number.
0008-add-missing-FTW_-macros-for-musl.patch seems to break code in areas
(rng, smack, selinux) where breakages can have security implications.
0002-don-t-use-glibc-specific-qsort_r.patch might introduce race
conditions that cause data corruption.
0007-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch makes
some functions behave different from what is expected by callers.
0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch and
0001-do-not-disable-buffer-in-writing-files.patch seems like an issue
that would require debugging the root cause and then addressing it.
All this looks bad, and is expected to become worse.
In this situation it would be better to not claim that using systemd
with musl would be a supported option.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next reply other threads:[~2019-05-23 10:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 10:33 Adrian Bunk [this message]
2019-05-23 12:22 ` Should systemd be marked as incompatible with musl? Burton, Ross
2019-05-24 1:45 ` ChenQi
2019-05-24 2:16 ` Khem Raj
2019-05-24 10:12 ` Adrian Bunk
2019-05-24 16:13 ` Khem Raj
2019-05-24 17:27 ` Adrian Bunk
2019-05-24 17:31 ` Khem Raj
2019-05-24 17:58 ` Adrian Bunk
2019-05-24 18:04 ` Khem Raj
2019-05-24 18:45 ` Adrian Bunk
2019-05-24 19:34 ` Andre McCurdy
2019-05-24 19:47 ` Khem Raj
2019-05-24 20:28 ` Adrian Bunk
2019-05-24 22:25 ` Andre McCurdy
2019-05-25 7:25 ` Adrian Bunk
2019-05-28 23:10 ` Andre McCurdy
2019-05-29 7:31 ` Adrian Bunk
2019-05-29 9:01 ` Khem Raj
2019-05-29 10:29 ` Adrian Bunk
2019-05-29 19:04 ` Andre McCurdy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190523103352.GA25084@localhost \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox