Re: preliminary patch for initrd support in Mach

[olafBuddenhagen]

Hi,

On Fri, Jun 11, 2010 at 03:16:04PM +0200, Jérémie Koenig wrote:

> As part of my debian-installer project[1] I have been working on
> initrd support for GNU Mach.
[...]
> 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?

> There were also concerns raised on #hurd that this is not quite
> hurdish and that its scope should be as limited as possible (read-only
> gzipped data to be handled by userspace),

Right.

> 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 --
but I think it indeed was brought up in the original discussion on the
list a couple of months ago.

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

Also, having the initrd implementation in a userspace process will
require some changes in the bootstrap process... OTOH, these will be
necessary for userspace drivers anyways.

> 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) should make the patch much
simpler, I don't see much point in reviewing the complex patch now.

-antrik-