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

[Adrian Bunk]

On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote:
> On Fri, May 24, 2019 at 10:59 AM Adrian Bunk <bunk at stusta.de> wrote:
> >
> > On Fri, May 24, 2019 at 10:31:25AM -0700, Khem Raj wrote:
> > > On Fri, May 24, 2019 at 10:27 AM Adrian Bunk <bunk at stusta.de> wrote:
> > > > On Fri, May 24, 2019 at 09:13:08AM -0700, Khem Raj wrote:
> > > > > On 5/24/19 3:12 AM, Adrian Bunk wrote:
> > > > > > On Thu, May 23, 2019 at 07:16:53PM -0700, Khem Raj wrote:
> > > > > > > ...
> > > > > > > but I think dropping
> > > > > > > systemd support completely from musl is not an option I would like to go
> > > > > > > with, there are cases where this makes sense. Especially when you have to
> > > > > > > cater to different set of devices from small to big, userspace remaining
> > > > > > > same is big advantage atleast in the world I am in.
> > > > > > > ...
> > > > > >
> > > > > > That's a good point - when arguing against systemd as default init system.
> > > > > >
> > > > > > systemd is bigger than glibc, therefore on very small systems where the
> > > > > > size of the C library matters using systemd is usually not an option.
> > > > >
> > > > > Yes, design-wise I concur, in practice, desktop distros rule the linux world
> > > > > and systemd is quite prevalent there,
> > > >
> > > > Desktop distros don't use musl - it wouldn't make sense.
> > >
> > > Yes,  what I was saying is that decisions on init systems and like that are
> > > influenced by desktops too. Since the apps are being written for across the
> > > board portfolio where some platforms are desktop/server driven some are
> > > more embedded
> >
> > The point is that most of the time using musl doesn't make sense.
> >
> > Definitely not on a desktop, and also not with systemd as init system.
> >
> > I haven't done exact measurements and it would also depend on the
> > architecture, but the only real-world benefit of using musl instead
> > of glibc for an OE user is something like "3 MB smaller in an -Os build".
> >
> > On many of todays embedded systems such a small size difference is
> > irrelevant. In these cases the correct solution that stays compatible
> > with everything else is to use glibc.
> 
> No, there is DRAM use difference too.

I didn't limit the size difference to the filesystem.

(But in practice RAM is usually a smaller problem than the filesystem.)

> > And on really tiny systems where every single MB counts,
> > all other design choices also have a high emphasis on size.
> >
> > Using systemd instead of busybox init (or some other small init system)
> > would cost you much more space than what the C library choice gave.
> >
> > And the current sad state of the systemd musl patching that makes it
> > compile but creates misbehaving functions and security vulnerabilities
> > makes it an even worse idea to use systemd with musl.
> >
> 
> I think we should put in plan for 2.8 and define the scope, since we
> are switching
> poky defaults to systemd,

Switching glibc builds to systemd as default is a reasonable decision.

Switching musl builds to systemd as default would be very bad.

Combining a tiny C library with a huge init system completely misses
the configurations where the tiny C library actually makes sense for 
users.

> this might have testing implications for
> musl especially from
> CI perpective

The CI should aim at testing what makes sense for users.

Offering musl becomes pointless if there is no small init system that 
is properly supported and tested with musl builds.

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