On Wed, Mar 6, 2019 at 5:23 PM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > On 07.03.19 01:33, Daniel Colascione wrote: > > > *There* *may* *be* *no* *filesystem*. > > A Linux system w/o any filesystem at all ? Well, that's interesting. 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. :-) 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. > > The only thing the kernel can really guarantee is its own> existence --- it should be entire in itself. > > I vaguely recall some option for linking in an initrd ... does this > still exist ? > > > If I'm hacking on an> Android kernel and say "fastboot boot mykernel" without making any> > changes to the device's boot filesystem, I should still be able to use> > tracing tools that rely on knowing the headers for the kernel with > > Fix fastboot to support initrd or use a remote filesystem ? 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 have a chance to make very useful tools work transparently everywhere, and without additional work across a fragmented and uncoordinated ecosystem. That's not nothing! While I appreciate the purity merits of a file-based approach, insisting on it will lead to a world where it'll be many more years before we can apply these powerful analysis tools universally. Human factors are just as important as technical ones if you want to actually get anything done, and in this case, a consideration of the human factors points toward the kernel as coordination point for kernel metadata. It'd be different if we were working in a more-coordinated system NT or FreeBSD, but this is Linux, where fragmentation starts as soon as you exit ring zero. That said, I think it's fair to want the configuration blob to be swappable and removable even in a monolothic, no-module system. There are lots of ways of meeting these requirements. > I'm doing embedded development all the day, and one of the first things > I usually set up for a project is an fully automatic netboot (or at > least usb boot). Shouldn't be so hard, and is a more generic solution. Yeah. I think every embedded developer quickly developers a rich set of shell scripts for this stuff. That's part of my point: if we can pull it off, existing toolsets, which we can't possibly change all at once, should properly propagate this kernel metadata without having to even realize that they're doing it. Practically speaking, the only universal mechanism is to bake something into the kernel image or one of its modules.
