On 8/20/19 11:38 AM, Adrian Bunk wrote: > On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote: >> On 8/19/19 9:55 AM, richard.pur...@linuxfoundation.org wrote: >>> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote: >>>> Should the limit be simply raised? The 256M setup is crumbling on >>>> several fronts (runtime tests, modernisation of X, various non-x86 >>>> qemu targets). Adding per-image/target exceptions, custom non- >>>> upstreamable patches, or sticking to deprecated configurations isn't >>>> the right thing to do, I think. >>> >>> What kind of devices/uses are we meant to be targeting? >>> >>> I believe OE is suited to optimised used cases where constraints on >>> size and performance are quite likely and supported. >>> >>> This is *exactly* the kind of thing we should be exploring and >>> supporting. systemd is not designed for some of the systems we target. >>> Changing some of its configuration shouldn't be a surprise. >>> >>> Having NFS taking up half the available memory doesn't make sense, >>> particularly when the sysvinit limits have worked for us for years. I >>> therefore appreciate Hongxu figuring out what the difference was and I >>> believe we should change this to something more suited for our target >>> audience, unless someone can explain why this is a bad idea. >>> >>> Similarly, forcing everyone to full GL stacks under qemu simply is not >>> acceptable. For example I might have a single container type image >>> which I want to load/test under qemu. Forcing such usage to require >>> 512MB memory for what could be a headless system also isn't right and >>> will just frustrate users. Users need to be able to access headless or >>> 2D configurations of it. >> >> Looking at what my customers are doing, I completely agree. I look at the >> design criteria for my customer's devices and I'm seeing 256MB as -very- >> common. >> More happens, but it's rare still. (But I have some customers with GB of >> ram, >> but that is usually to support their application, but the base system!) >> >> (Note, I do have customers -with- graphics requirements [X11] that are in the >> 128/256 MB ram ranges. In most cases OpenGL is something they would like, >> but I >> don't believe it's a hard requirement for them.) >> >> I do still have many customers with 128 MB of ram requirements. So it's >> important for us to set a reasonable baseline (256MB). So going under this >> requires 'work', but I think that is acceptable. > > There is also a certain disconnect between these numbers and the > constant pain for everyone of keeping everything building with > musl for small size gain. > > 128 MB RAM and 16 MB flash would be a configuration where I would not > worry about size enough to consider glibc a problem. > > Is there real-world demand for running X11 with musl?
Size is only one reason for musl, the other is to have a non-GPL libc in the device. --Mark > Is there a CI setup ensuring that disk and RAM usage of relevant > musl setups don't regress - which might be more than the gains > of musl compared to glibc? > >> --Mark > > cu > Adrian > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
