Support for musl C library

[kanavin]

musl is a small, embedded-oriented alternative to glibc. These patches address issues when using systemd-bootchart with it, and are taken from Yocto project:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/systemd-bootchart/systemd-bootchart

[xnox]

Why don't you patch yocto's build of musl to provide printf.h i thought that's what one normally does. I.e. https://github.com/matijaskala/musl-patches/blob/master/printf.h.patch

As you are not copyright holder, it would be nice to hear from Tim or Intel if they want this contributed.

Overall, normally systemd & systemd-bootchart target full glibc based systems. So I am kind of indifferent to taking this patches.

Looks like CI has regressed and not running on this repository. We should fix CI, and do build against glibc. And if we are to merge this patch, also enable builds against musl to ensure it doesn't regress. As most integrators do not use musl.

[moto-timo]

I no longer work for Intel, but I do still work on the Yocto Project and these patches are still valid. I will note that I was refactoring the work of others (Emil Renner Berthing @esmil and Khem Raj @kraj). I will also note that Alpine Linux only uses musl.

[kraj]

Why don't you patch yocto's build of musl to provide printf.h i thought that's what one normally does. I.e. https://github.com/matijaskala/musl-patches/blob/master/printf.h.patch

musl has decided to not implement it and carrying such a patch will be permanent diversion. Perhaps someone can
come up with a libgnu-compat or something maybe that can be considered.

As you are not copyright holder, it would be nice to hear from Tim or Intel if they want this contributed.

some of them are from me and its fine to contribute them here.

Overall, normally systemd & systemd-bootchart target full glibc based systems. So I am kind of indifferent to taking this patches.

yes, and perhaps some of these patches will help to reduce the delta for non-glibc systems without much of trouble to maintainers. if not thats fine.

Looks like CI has regressed and not running on this repository. We should fix CI, and do build against glibc. And if we are to merge this patch, also enable builds against musl to ensure it doesn't regress. As most integrators do not use musl.

That will be awesome.

[bluca]

musl has decided to not implement it and carrying such a patch will be permanent diversion. Perhaps someone can
come up with a libgnu-compat or something maybe that can be considered.

As mentioned many times, these sort of patches should be maintained in the musl package in distributions that ship it, rather than being sprinkled all over the place. The standard on Linux is glibc, and Linux distributions need to support that standard.

[kanavin]

musl has decided to not implement it and carrying such a patch will be permanent diversion. Perhaps someone can
come up with a libgnu-compat or something maybe that can be considered.

As mentioned many times, these sort of patches should be maintained in the musl package in distributions that ship it, rather than being sprinkled all over the place. The standard on Linux is glibc, and Linux distributions need to support that standard.

glibc is not any kind of standard, it's an implementation of the standards, which are defined in published POSIX and ISO C documents.

If systemd aims to be compatible with only one implementation of those specifications, then please don't do so under the pretense of 'standards'.

[bluca]

It's the standard for Linux. 'standard' doesn't just mean something certified by ISO or some other committee.

[kanavin]

It's the standard for Linux. 'standard' doesn't just mean something certified by ISO or some other committee.

It is not required by the linux kernel, or by userspace. The only significant piece that is glibc-specific is systemd.

Yocto ships musl systems, and so does buildroot, so musl is a viable, and widely used option in embedded Linux.

[bluca]

It's the standard for Linux. 'standard' doesn't just mean something certified by ISO or some other committee.

It is not required by the linux kernel, or by userspace. The only significant piece that is glibc-specific is systemd.

Considering that there's plenty of musl-specific patches all over the place, I am having a really hard time believing that - just a quick grep of 'musl' through Yocto's git log shows a very different picture

Yocto ships musl systems, and so does buildroot, so musl is a viable, and widely used option in embedded Linux.

Then Yocto and Buildroot have three choices:

1. Convince musl to be sensible and implement widely used and useful interfaces
2. Maintain a fork/patches musl version that implements widely used and useful interfaces
3. Drop support for musl given it doesn't implement widely used and useful interfaces

We are not going to be stuck with the lowest common denominator and drop widely used and useful interfaces, sorry.

[kanavin]

It is not required by the linux kernel, or by userspace. The only significant piece that is glibc-specific is systemd.

Considering that there's plenty of musl-specific patches all over the place, I am having a really hard time believing that - just a quick grep of 'musl' through Yocto's git log shows a very different picture

These patches happen because upstreams unknowigly introduce glibc-specific code, which is then fixed in yocto, and fixes are submitted back to them. The only upstream which actively rejects such fixes is systemd, others tend to accept them.

Other points I'm not going to continue to argue with. Your position is clear.

[bluca]

It is not required by the linux kernel, or by userspace. The only significant piece that is glibc-specific is systemd.

Considering that there's plenty of musl-specific patches all over the place, I am having a really hard time believing that - just a quick grep of 'musl' through Yocto's git log shows a very different picture

These patches happen because upstreams unknowigly introduce glibc-specific code, which is then fixed in yocto, and fixes are submitted back to them. The only upstream which actively rejects such fixes is systemd, others tend to accept them.

I can't be bothered to check, but I'm pretty sure I saw other projects rejecting some of these changes too in the past. And rightfully so, given some of those changes are really wrong and introduce serious security bugs, such as dropping AT_SYMLINK_NOFOLLOW all over the place.

[kanavin]

I can't be bothered to check, but I'm pretty sure I saw other projects rejecting some of these changes too in the past. And rightfully so, given some of those changes are really wrong and introduce serious security bugs, such as dropping AT_SYMLINK_NOFOLLOW all over the place.

You don't need to check. As someone who is maintaining the bulk of core Yocto recipes I'm telling you: musl fixes tend to be accepted. I have looked at one such just now, to confirm it can be dropped on a version update:
libcgroup/libcgroup#236

The only patch in Yocto that even mentions AT_SYMLINK_NOFOLLOW is another rejected patch to systemd proper. It may be technically incorrect and in need of a rework, but you can't generalize from that to upstreams generally not willing to support musl. The only one that holds that position is systemd.

Given all this, should Yocto documentation recommend avoiding using systemd with musl, as it requires a ton of custom patches? Would you be ok with users of yocto seeking alternatives to systemd if we do so?

[bluca]

Given all this, should Yocto documentation recommend avoiding using systemd with musl, as it requires a ton of custom patches? Would you be ok with users of yocto seeking alternatives to systemd if we do so?

No, instead Yocto's documentation should recommend to avoid using musl altogether, given how projects have to be patched in such a broken way to adapt to its outdated and broken interfaces, introducing bugs and security issues in the process.