On Fri, May 24, 2019 at 12:34 PM Andre McCurdy <armccu...@gmail.com> wrote: > > 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.
rightly so, and it can also mean that project moves away from OE if headwind is too strong. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core