Re: SILO/GRUB coordination

[Gordon Matzigkeit]

>>>>> Niels Möller writes:

 NM> Gordon Matzigkeit <address@hidden> writes:
 >> I feel like the situation got better when the build environment
 >> changed so that you could run the GRUB shell under your favorite
 >> OS.  It helped make many kinds of bugs easier to track down.

 NM> What this means is that you already have two "backends", one
 NM> low-level PC BIOS thing, and one that runs on top of a unix-like
 NM> environment.  sparc/openboot support would "only" be yet another
 NM> one.

Yes.  The cost of implementing a unix-like backend for a single
platform was acceptable.  I think that cost will increase rapidly the
more platforms we add, especially if we want to take full advantage of
cool platform tricks like embedded FORTH.  I don't particularly want
to impose a PC-centric API on every boot environment.

 >> I'm operating under two main pressures (which may or may not be
 >> real): I believe GRUB should provide a programmable environment to
 >> allow people to do useful things with their machine even before
 >> booting;

 NM> I see. From that point of view, using fig makes more sense. Would
 NM> using fig be enough to be able to do useful things, or would one
 NM> need fig *and* some programming language?

Without any special support, you can build Figure primitives out of
your favorite programming language (in my case, C), then you write
scripts that use those primitives.

It gets interesting when you start building primitives that allow you
to write new primitives at runtime.  The most low-level example of
this would be a tiny assembler, so that you could write a machine code
primitive, and use it at your leisure.

 NM> I wonder how it would interact with openboot? SILO (at least the
 NM> old version I'm using) is like a program started from the boot
 NM> prompt, it takes full control, and can either boot something else
 NM> or return back to the boot prompt. Ideally, one would want to be
 NM> able to mix GRUB and FORTH in some way, but I have no idea if
 NM> that is possible.

I see that as possible.  A key concept in all this translation is
support for different languages in parallel.  So, you define some code
that specifies both a C or scripted definition and a FORTH definition,
then the FORTH definition is used only when FORTH is available.

 NM> As for programmability, I suspect that one thing that will limit
 NM> the usability of any boot time programming environment is how
 NM> convenient it is to save (as well as load and edit)
 NM> programs.

Older FORTH systems were based around the unit of a `screen', which
was basically a disk block, and you referred to them from other
screens by number (and had a command to run a screen editor).  It
would be nifty to write to a filesystem, but I think that's too much
complexity for a bootloader. ;)

Seriously, though... I expect that basic write support would just be
done by reserving a bunch of space at the end of the stage2, and
writing into that space when needed.  That should give enough
elbow-room to do interesting things, and possibly even load modules
that implement writable filesystem support.

 NM> I've never done anything complex in openboot (and I don't really
 NM> know FORTH), but I find it very useful for looking around in the
 NM> machine, see what disks are available, etc.

Yeah, that's the point of all this: to have a truly useful environment
for troubleshooting and playing with.

-- 
 Gordon Matzigkeit <address@hidden>  //\ I'm a FIG (http://fig.org/)
Committed to freedom and diversity \// Do Screen (http://fig.org/gnu/screen/)