Re: Initrd support & ext2fs bugfix

[Marco Gerards]

Johan Rydberg <address@hidden> writes:

> Jeroen Dekkers <address@hidden> wrote:
> 
> :     * loader/i386/pc/linux.c (pupa_rescue_cmd_linux): Check whether
> :     pupa_file_read fails.
> :     (pupa_rescue_cmd_initrd): Implement.
> 
> I've been thinking about PUPA a bit lately.  The loaders go into sysdep
> directories as of now.  This will result in a lot of duplicated code when
> PUPA gets ported to other platforms.  Though, it minimizes the need for
> ifdefs for a perticular platform (which is a good thing, IMHO. )  

This is true for some loaders, for other loaders it is not possible to
share code.  The linux loader on the PPC works completely different
from the PC version.

> Most of the code in a ELF loader is generic.  The only platform-dep code
> is validity checks and the invoktion of the kernel.

I agree.  I plan to make a generic loader for ELFs someday when I
fully understand what it should be capable of.  For example the linux
loading code for the PPC has some weird stuff that should be added.

> As soon as PUPA gets ported to, for example, PowerPC, new constrains will
> be put on the loader.  On the PPC platform, the bootloader must pass the
> entry point to the IEEE 1275:1994 firmware.  So if the loader is generic,
> there must be a hook for this.

Right.

> Say that there is a PUPA module that implements OpenFirmware, then that
> needs to pass its entry point to the loaded kernel.  So there is need 
> for hooks for that aswell.

Now I am passing the entry point that was passed to PUPA.  I will take
care of this.

> So what do you say.  Is it worth it to make (some) loaders generic?

When it is possible, absolutely.  Even some different loaders can
share code, like the multiboot loader for the i386 and the linux
loader for the PPC.

Especially the new multiboot loader should be mainly implemented in
the generic code with some arch specific code to fill in the missing
bits.

Johan and I talked on IRC about the next multiboot.  We will work on
this and share the ideas we have soon.

Thanks,
Marco