On Tue 14 November 2017 10:42:48 John Hughes wrote: > Of course SVR4.2 could be ported to an ARM SoC -- you'd just put /stand > on the internal NAND. (/stand was the SVR4.2 name for what Linux called > /boot).
Let me put it straight for you: /noot doesn't get you anywhere to bring up a system. Of course you know that, so lets assume you agree we need the whole stuff bin, sbin, lib, var, etc, etc, on your rootfs too. Now with systemd and all that ensues, your claim is there must be /usr/* on rootfs as well. Thats where's the problem starts now: on some SoCs/platforms there might be only a few MB of NAND and no other storage (particularly none that is always available without additional mounting of filesystems and storage technologies needing drivers not monolithic in kernel). Obviously a systemd | usr_on_/ system would not fit onto that tiny NAND, while a 'classical orthodox' system is supposed to work just fine *without* /usr/ at least in a singleuser mode which may well be all you want for your tiny embedded system like they are more and more popular and all but obsolete relics like you claimed. To put it utterly clear and unambiguous: systemd explicitly ignores the needs of tiny embedded systems, Poettering been very clear on that. And distros follow this path by introducing policies like mandatory /usr/ on rootfs and successively phasing out support for other init systems. Requiring embedded- system-developers to sort out and "unmerge" the /usr/?bin vs /?bin and */lib/ stuff is backward in thinking. It's those who need stuff form /usr/* in early boot / init who are in charge to find better ways to solve their (pretty bizarre) problems than to just mandate all /usr/ being available after just rootfs got mounted. It's *not* about when and how to keep or mount /usr/, it's about init system and early boot (or a minimal system) is supposed to *not need /usr/* at all - at least in a first approximation, usecase specific minor modifications might apply. /j _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
