[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SILO/GRUB coordination
From: |
Gordon Matzigkeit |
Subject: |
Re: SILO/GRUB coordination |
Date: |
04 May 2001 08:15:59 -0600 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 |
>>>>> 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/)