Re: SILO/GRUB coordination

[Gordon Matzigkeit]

>>>>> Niels Möller writes:

 NM> Gordon Matzigkeit <address@hidden> writes:
 >> 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.

 NM> I'm not sure you really need any advanced macros.

It's true that they're probably unnecessary if you are content with
staying with C/assembler for the development environment, and using a
different syntax for any runtime commands.  This is what GRUB has done
so far.  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.

What I'd like to see is a continuation of that trend.  OpenFirmware
has its modified FORTH interpreter, and I bet you they do a lot of
simulation of their boot loader.  One of Figure's goals is to provide
a much friendlier environment than FORTH, but still give access to the
machine internals.

FORTH Is Great Unless Relaxation's Expected. ;)

 NM> For accessing devices, what you need is probably some kind of
 NM> pseudo-filesystem interface, with operations like [...]

Absolutely.

 NM> Or am I oversimplifying things? Device names like sd(1,2,3)
 NM> doesn't map directly onto a file system design, but perhaps one
 NM> could create some general parametrized-names abstraction, or hack
 NM> around it some other way. In particular, is it desirable to do
 NM> TAB-completion of sd(1,2,3)-style names?

I think it's still desirable, and possible.

These issues are somewhat easier if you consider representing a web of
nodes (where every node can be a file or a directory) instead of a
filesystem.  OpenFirmware has a similar thing, the point of which is
to allow property lists for devices.

 NM> There can be several implementations of the pseudo-filesystem
 NM> above, selected at configure time or at runtime, as
 NM> appropriate. That kind of design is quite standard.

That sounds fine to me.

 NM> What you're doing with fig is cool,

<blush>

 NM> but for GRUB I feel it may be appropriate to apply the "do the
 NM> simplest thing that could possibly work"-mantra. I'm guilty of
 NM> reading the XP book recently...

:)

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; I believe
GRUB should provide the same kind of environment under a normal OS, so
that people can try it out, or debug it.

If somebody doesn't share those goals, then what I'm doing will look
rather strange.  It may still look strange even if you share those
goals.

The point though, is that what I'm doing with Figure is modular: it
will be possible to use some modules without needing others: you may
want the pseudo-filesystem interface without a multithreading
environment, or you may want the command-line interface without the
programming language.

So, yes... I'm very much into the simplest thing, but I also want to
provide enough to be useful.  What that means to GRUB will depend on
what people think is useful about Figure, and what should be done
differently.

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