Re: GRUB plans...

[Yoshinori K. Okuji]

[Erich, I add the mailing list address@hidden to Cc, so that other
people can see my opinion as well. I hope that you won't mind.]

First of all, I'm sorry that I'm too late to reply. I was quite busy!

> You probably saw a few messages a few months back I sent when I was
> starting to look into trying to tackle the BIOS mapping problem once-
> and-for-all.  I have been doing experiments on-and-off during my few
> spare cycles in the intervening time.
> 
> This is a strong interest of mine, and I think solving it (or coming
> up with the 95% solution I mentioned, at least) would make it so that,
> except for some rather exotic situations, you can have predictable
> installations without the OS having to know anything about BIOS mapping.

That's also my intention. So I did some work on the BIOS mapping
problem, although it didn't work quite well. I have another
implementation that is based on what you wrote in Multiboot Standard
0.6, that is to say, the method using Virtual 8086 Mode, but it is far
from complete.

As you may know, I started to modify the Multiboot Specification,
which will be published as version 0.7 someday. It is not very easy to
figure out what are added by me, because I have mistakenly dropped out
the chapter "History", but you can see that the information about BIOS
mapping is now included in the Multiboot information
structure. Therefore, it is *necessary* to implement a BIOS mapping
method, to release the next (formal) version of GRUB.

> I want to sync up with you on what you're planning...  I saw a comment
> you sent along saying something along the lines of a "rewrite of GRUB",
> and am curious what you're up to with it.  Replacing many of the
> commands with a script language?

Maybe. Another important plan is to add I18N support.

> One is that, kind of like the NTLoader does, actually have the Multiboot
> info structure provide a set of function pointers (with a defined way to
> work with stack frames) for the ability to read the "disk", so that
> OSes could probe hardware and load it at boot-time without having to
> pre-define it.  You guys may have already talked about this a on the
> email list, I haven't checked my archive carefully enough yet.

That sounds similar to EFI. If you add such a feature into the
Multiboot Specification, what is the difference between the Multiboot
Specification and EFI? I don't have any strong objection, but I think
the advantage of the current Multiboot Specification over other
specifications/standards is that it is easy to get information,
because the information is basically ``static''.

> Finally, in my own OS experiments, I'm starting to look at multi-arch
> support, and have been starting to consider how to make GRUB work with,
> say, the Mac PPC and other environments.  The Mac booting world is
> something of a mess, so having some way to make it consistent for them
> might be a service there too...

I agree. Personally I want to have UltraSparc support, though... ;)

BTW, I think I should write more details about my plans. I hope I will
have time to do that soon.

Regards,
Okuji