Re: SILO/GRUB coordination

[Christoph Plattner]

I really like the idea of having GRUB on many platforms.

But again I want to point out, that in my oppinion the 
environment stuff is important and can especially be
useful in connection with SPARC machines.

The boot loader GRUB is for me the missing link between
the "poor" PC BIOS and a useful boot monitor like OpenBoot.
But the only thing GRUB cannot handle is the environment
stuff. I think of a method keeping variables (how to save ?)
accessing them via `$VARIABLE', setting them via `VARIABLE=xxx'.
In all commands (including menues or config files) the variables
can beset and used. `printenv' displays a list, and the
for example `envmodul' create a Multiboot modul including 
the environment (perhaps we use the `--dos' and `--unix' option
for the CR/LF problem).

Further there should be built-in variables, like the $MEM,
$IP, $IP_SERVER, etc...

In connection with SPARC also the SPARC OpenBoot variables 
(a part of them, or all, ?) can be exported.

With this a linux kernel can be loaded with

        title Linux Boot
        CONSOLE=ttyS0
        root (hd1,0)
        kernel /boot/vmlinuz mem=$MEM console=$CONSOLE

I hope my idea is interesting for you.

With friendly regards
        Christoph


"Niels Möller" wrote:
> 
> 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.
> 
> I'm not sure you really need any advanced macros. For accessing
> devices, what you need is probably some kind of pseudo-filesystem
> interface, with operations like
> 
>   read the "root directory"/devices list,
> 
>   read subdirectories (partitions, directories on filesystems),
> 
>   read a file into memory.
> 
> Or am I oversimplifying things? Device names like sd(1,2,3) doesn't
> map directly onto a file system design, but perhaps one could create
> some general parametrized-names abstraction, or hack around it some
> other way. In particular, is it desirable to do TAB-completion of
> sd(1,2,3)-style names?
> 
> I don't know about the other aspects of the system that grub needs to
> know about.
> 
> There can be several implementations of the pseudo-filesystem above,
> selected at configure time or at runtime, as appropriate. That kind of
> design is quite standard.
> 
> What you're doing with fig is cool, but for GRUB I feel it may be
> appropriate to apply the "do the simplest thing that could possibly
> work"-mantra. I'm guilty of reading the XP book recently...
> 
> Regards,
> /Niels
> 
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub

-- 
-------------------------------------------------------------------------
private:        address@hidden
company:        address@hidden