Re: SILO/GRUB coordination

[Gordon Matzigkeit]

[I'm adding address@hidden because I think it's relevant to the
other GRUB developers, and I don't see that anything private has been
said.  Please accept my apologies if this was a bad call.]

>>>>> Ben Collins writes:

 BC> On Thu, May 03, 2001 at 04:26:14PM +0200, Niels M?ller wrote:

 >> The good thing about coordinating with GRUB would be to share the
 >> code for reading filesystems, configuration files, UI, etc.

Agreed.  That would be the main thing merging with GRUB could offer,
aside from a common name that we could use to increase interest in one
anothers' projects.

 >> 1. adapt SILO's stage1 loader as an alternative stage1 loader in
 >> GRUB,

 BC> SILO's stage one loader merely sets up the system so it can
 BC> execute a second stage loader (it has a stage1 loader for sparc
 BC> and sparc64). So it should be able to execute any sparc code as
 BC> the second stage loader, assuming it fits into the 512k(?) that
 BC> is allowed.

That's essentially the same role that GRUB's stage1 has: to make up
for arbitrary limitations in what the BIOS/monitor can load itself.
The PC stage1 has to fit in under 380 bytes, which is enough code to
load the stage2 from floppy or hard disk, using LBA mode if necessary.

That all works in such a tiny space using some creative assembly
hacking done by Okuji and others.  Maybe there's a way to merge the
sparc and sparc 64 stage1s (or maybe not, I don't know how different
the architectures are)?

 >> 2. adapt the final steps in the second stage loaders; GRUB follows
 >> the (pc-specific, I think) multiboot-standard, while I imaging
 >> sparcs do things differently. I'm not terribly familiar with
 >> either system, though.

 BC> The second stage loader will need to be familiar with SPARC's
 BC> Boot PROM so it can recognize devices, etc.

Absolutely.

This is where my interest comes in: I believe it is worthwhile to have
a common code base for bootloaders on multiple platforms.  However,
the only real way of making that happen is with configure scripts and
C preprocessor macros.

That requires a lot of thought to scale well, such as isolating the
common code in separate files, and parameterizing things so that they
are built differently on different platforms.

My plan has been to implement a more powerful macro processor than
CPP, and then to use it to process the sources more flexibly.  This is
the same software I'm recommending as an extension language for GRUB
itself.  I have been writing it with the intent of fitting it into
GRUB, so I know the specific bloatages that can be eliminated in order
to squeeze out some extra memory or disk space.

Once GRUB gets its own extension language, I'd say it could rightfully
be called a mini-OS.

The name of the software is GNU Figure (http://fig.org/figure/), and
it's developing at its own pace.

 >> I can't say whether or not it's really worth the effort.

 BC> I'd say it is worth looking in to. Also note that sparc doesn't
 BC> have the same type of initial terminal as PC's, so that has to be
 BC> taken into account. At the second stage loader, it will only have
 BC> the black and white text console.

We have a similar constraint when working from serial console.
Currently we assume vt100 terminal capability, but there has been some
discussion about making a separate dumb-terminal UI as a fallback for,
say, teletypes. ;)

-- 
 Gordon Matzigkeit <address@hidden>  //\ I'm a FIG (http://fig.org/)
Committed to freedom and diversity \// Go Figure (http://fig.org/figure/)