On Fri, May 24, 2019 at 11:46 AM Adrian Bunk <b...@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 <b...@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 <b...@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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
