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

[Khem Raj]

On Fri, May 24, 2019 at 12:34 PM Andre McCurdy <armccurdy at gmail.com> wrote:
>
> On Fri, May 24, 2019 at 11:46 AM Adrian Bunk <bunk at stusta.de> wrote:
> >
> > 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.
>
> For new projects yes. However I know of a project (a big project,
> shipping millions of devices) which picked systemd and glibc long ago
> and is now running out of space. They already have various solutions
> to free up Flash (some apps switched to being runtime downloadable,
> etc) but if/when more savings need to be found then switching from
> glibc to musl might be a less invasive change than switching from
> systemd to some other init system. We obviously shouldn't make
> decisions for OE today based on the historical decisions of one
> project, but I just want to make the point that real world projects
> have a lifetime and may end up with a combination of systemd + musl
> due on past decisions that may not make sense for a new project
> starting today.

rightly so, and it can also mean that project moves away from OE if headwind
is too strong.