Re: preliminary patch for initrd support in Mach

[olafBuddenhagen]

Hi,

On Mon, Jun 14, 2010 at 10:31:00AM +0200, Samuel Thibault wrote:
> olafBuddenhagen@gmx.net, le Mon 14 Jun 2010 09:00:05 +0200, a écrit :

> > > 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

I see... Didn't get around to read the logs yet; but I hope I will at
some point...

> > 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.

I meant without any new kernel mechanism required specifically for
initrd. This is definitely possible -- though probably more complicated
than the current approach using a simple kernel driver...

> 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.

I was thinking of a task having the data and the code to provide a store
only... Though having the code of the whole filesystem server would
indeed have the advantage of avoiding the bootstrapping problem.

> 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.

Good point.

> 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 / .

Not sure what you mean. The point is that currently the root filesystem
doesn't rely on any external processes except for the kernel. Any
solution involving an extra userspace task for the store (be it a
userspace disk driver or a non-kernel initrd) will require a modified
boot process.

> > > 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?

I was talking about a simplyfied kernel driver here, avoiding the
unnecessary in-kernel copy. I think the code will be much simpler, and
thus I don't see much point in reviewing the current implementation.

-antrik-