On Thu, Mar 07, 2019 at 09:41:24PM +0100, Enrico Weigelt, metux IT consult wrote: > On 07.03.19 02:49, Daniel Colascione wrote: > > > Entirely FS-less operation is uncommon, granted. :-) I guess I've just > > spent too much time debugging emulators that refuse to mount their> root filesystems. :-) > > Fix these emulators ? > > > There are legitimate reasons why a device's> filesystems might not be rw-mountable though, and I can imagine a > > world where I want to attach tracing tools *very* early. > > Ok, but the filesystem where the modules live is mountable, right ? > > > Sure. There's some support for a ramdisk already in fastboot. But just > > including a blob in initrd doesn't *automatically* make it available > > to userspace in any uniform way. With Joel's approach --- which> defines both a propagation mechanism and an access interface --- we > > I can define such an interface with a few words: > > * the kernel headers lives in a (compressed) squashfs image in the > module directory for the corresponding kernel version: > /lib/modules/<version>-<flavour>/headers.img" > * this image shall be mounted at a canonical mountpoint, eg: > /usr/src/linux-headers-<version>-<flavour> > * the kernel needs to support squashfs (may be module or built-in) > > That's it. I don't need to touch a single line of kernel code for that, > just a very simple and small convention. Ick, no, no more squashfs please, let's just kill that mess once and for all :) Again, putting this in a simple compressed tar image allows anyone to do whatever they need to with this. If they want a full filesystem, uncompress it and use it there. If they just want it in-memory where they can uncompress it and then discard it, that works too. And if no one wants this, just don't select the config option and do not load the module with this data in it. Just like /proc/config.gz is today. thanks, greg k-h
