[OE-core] Should systemd be marked as incompatible with musl?

[ChenQi]

On 05/23/2019 08:22 PM, Burton, Ross wrote:
> On Thu, 23 May 2019 at 11:34, Adrian Bunk <bunk at stusta.de> wrote:
>> 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.
> I think I have to agree with you: several of the extensions are for
> security purposes, so we're potentially actively introducing issues.
>
> Ross


I suggest we only apply these musl patches when the libc is musl.

SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') == 'musl' 
else ''}"

In this way, these patches do not affect glibc users. People who 
actually use musl will test these patches and maybe improve them if they 
really care about it.

For example, the following patches are written by me.

0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch and
0001-do-not-disable-buffer-in-writing-files.patch

These two patches are to solve runtime problems in musl based system. I 
knew there's something different in buffering mechanism between glibc 
and musl that causes this problem, but I really did not want to spend 
time digging into it. And as systemd was using unbuffered way for 
writing files for a long time, I just disabled them.

As Adrian and Ross pointed out, these patches are introducing potential 
security problems. I agree that we should do something about it. At a 
minimum, the glibc based system should not be affected.

I'll send out patch and please help review it.

Best Regards,
Chen Qi