Re: preliminary patch for initrd support in Mach

[Samuel Thibault]

olafBuddenhagen@gmx.net, le Mon 14 Jun 2010 09:00:05 +0200, a écrit :
> > The current version of my d-i images use this as the root filesystem,
> > with grub loading an ext2 filesystem image from the boot CD. Which is
> > not that good considering that the required free space on / will
> > likely vary from installation to installation. So a better solution
> > will be needed in the long run (union a tmpfs over / early on?)
> 
> You mean instead of reserving some space in the initrd image, you want
> to use something that can grow dynamically? Not sure it's worth the
> effort. Isn't the size of the initrd FS fixed in Linux as well?

Nope, nowadays it's a cpio unpacked in a tmpfs.

> > or that modifying Mach for this purpose is misguided and should be
> > avoided (for instance by embedding the initrd in a dedicated section
> > of an elf module).
> 
> Hm... I don't remember this variont actually being mentioned on IRC --

It's a recent discussion between slpz and me

http://richtlijn.be/~larstiq/hurd/hurd-2010-06-10 , starting at 16:40:52

> but I think it indeed was brought up in the original discussion on the
> list a couple of months ago.

The discussion a couple of months ago wasn't very lengthy actually.

> I'd certainly prefer a solution that doesn't require kernel support --
> though the implementation will probably be more complicated.

The kernel has to be involved anyway, since that's the one piece of
software that gets passed the data. It needs to provide it some way or
the other.

> Also, having the initrd implementation in a userspace process will
> require some changes in the bootstrap process...

ext2fs needs to find its data, yes.

One relatively simple portable way I could find is to build a libext2fs,
which has all of ext2fs (including main etc.) except a "disk" array and
"disksize" integer, which you can provide by linking it against a .o
containing disk and disksize.  Then you can pass the result to grub.
This can work for other kinds of FS of course.

What I really dislike however is that it's then quite difficult for a
user to tinker with an existing image, as opposed to mounting an ext2fs,
unpacking a cpio, etc.

> OTOH, these will be necessary for userspace drivers anyways.

Maybe not. A first module could be started to provide a / containing
/dev/hd0, and a second module could use that to open /dev/hd0, and
attach itself to / .

> > My goal is to get a basic installer working as soon as possible, so
> > I'm going to move on to the other parts of my project for now unless
> > some critical problem with the attached patch shows up. However I
> > intend to return to this as soon as possible and I would appreciate if
> > we could discuss it in the meantime.
> 
> Considering that mapping the memory of the module readonly (and doing
> the rest with a gunzip/copy/memory store)

How to do that?  How do you know the address and the size?

Samuel