On Fri 09 Jun 2023 at 13:12:36 (+0100), James Addison wrote: > On Fri, 9 Jun 2023 11:52:28 +0100, <deb...@lionunicorn.co.uk> wrote: > > On Fri 09 Jun 2023 at 10:44:23 (+0100), James Addison wrote:
> > > (in terms of practicalities: I realize that if there were no > > > initrd/initramfs, then the kernel would need to know or be able to > > > load a (standard?) module in order to read the target filesystem. the > > > former module could either be compiled-in (but that could reduce > > > filesystem diversity), or it could be loaded from the 'true' root > > > filesystem block device extents somehow. > > > [ … ] > > You seem to be keen to invent something. But the invention (initramfs) > > has already been invented. If you read around the topic in some depth, > > you'll perhaps realise the benefits it brings. > > > > BTW, loading stuff from the 'true' root in the absence of the > > initramfs (or being compiled in already) merely begs the question. > I have to admit that I've never completely understood the phrase/idiom > 'begs the question'. It seems to be misinterpreted relatively often, > so I wonder if it too could be refactored. You made a circular argument, hinted at by the word "somehow". To load a module from the 'real' root filesystem, you need to mount it, which is precisely what you're trying to do in the first place. > I think the design has worked extremely well and provides plenty of > versatility. The success of various operating system distributions > following this model demonstrates that fairly comprehensively, I > think. > > I'd see (re)invention as an antipattern for a system like that. But > if it's possible to refactor it into something that maintains the same > benefits while being simpler to understand and maintain, runs less > code during system startup, and can simplify operating system > backup/inspection/transfer/restore operations, then I think it could > be worth considering. Running less code might have to be weighed against compiling in more code, or else losing the flexibility gained by only loading what you actually need at run/startup time. But you could work on designing/refactoring a system without writing any actual code to implement it. Perhaps have a go? > Also agree that I should learn more about it in depth, and that it's > possible that I'll end up realizing that it's a near-optimal solution > already. Cheers, David.
