Re: GRUB plans...

[erich]

"Yoshinori K. Okuji" <address@hidden> wrote:

> [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.]

Not a problem...


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

Heh, sorry for my late reply from the weekend myself...


...
> 0.6, that is to say, the method using Virtual 8086 Mode, but it is far
> from complete.

Are you planning on completing your VM86 implementation in the
reasonably near future?  If not, I could complete/robustify mine.

It also may turn out that VMWare-3.0 may solve the shortcut BIOS
problem that VMWare-2.x had.  (VMWare-2.x would not use simulated
I/O instructions in it's BIOS, just special callouts to the emulator
monitor)


> 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 noticed your changes.  I'm going to look them over again...  but
I think the mapping ideas I have been playing with are a superset.

There are really 2 problems at work here:

  1) The one everyone wrestles with in the bootloader proper right now,
     and I identified in my "BIO Mapping" proposal:  Trying to map from
     BIOS device numbers to controllers and disks on them.

     The VM86-based mapper seems like it will do a 95% solution here...


  2) The problem you and others working with GRUB post 0.5 have looked
     at:  When setting up the bootloader within an OS, knowing which
     *OS* devices map to which BIOS device numbers.

     LILO installation makes some OK assumptions so that the end-user
     theoretically just has a nice default configuration.

     So, what I've been worrying about is the end-user problem of
     saying:

     "boot off of disk/partition X/Y"

     and having it do so, even if you move the disk around.

     Essentially, if there was a way for the OS-level installation
     code to identify where it's booting in the GRUB config file,
     then GRUB can go off and find the disk and report the VM86-map
     to the OS, thereby not even caring what BIOS disk number it's
     installed on.

     This will probably take a bit more thought.  Disk and paritition
     signatures still tend to be annoying...  but if an OS already has
     one, why not use it?  (this is in part where my interest in maybe
     a script language or somesuch gets interesting...  we wouldn't
     need OS-specific code for these cases, just a hunk of script code
     to include for each case of interest)


> > 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.

I think we talked a little bit about I18N before, but essentially I still
know next-to-nothing about I18N support other than the idea of using a
UTF-8 -like Unicode/ISO-10646 set, which I understand doesn't work very
well for many of the "asian" languages.


> > 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''.

EFI is still MUCH more complicated.  Have you looked at the section
on partitioning.  Ugh!

Yes, the main point I had with elements of the Multiboot stuff is that
they were supposed to be simple and east to implement.

But I can't see any other way around this kind of thing.


> > 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.

Sounds good.

I should probably write up a bit more detail about the mapping ideas
I've been playing with.


Essentially, what I'm after is:

  --  Multiplatform:  Bootloaders on other arch's sometimes suck
      more than x86.  ;-)  Or they're just inflexible.

      This would entail some modularization and testing, but I think
      it's probably not all that hard to port the filesystem code, for
      example.  We'd have to write some partition code that other
      hardware expects to see, but that's not a big deal.

      Then there are the hardware-dependent bits to write, of course.


  --  Mapping problem solved (on x86):  Includes elements of:

      --  VM86-mapper to produce BIOS --> OS mapping.

      --  Mapping mechanism from OS --> DISKS  (then GRUB can just find
          the disk as necessary in the map of available disks from the
          BIOS)


  --  [maybe?] Script language:  Some elements of wanting to do some
      sophisticated functionality here...  but as much as anything else
      I realize there are corner-cases that keep creeping into the code,
      and it will get more ugly over time.  We could have some builtins
      that would handle most of the well-known ones.


  --  Installation:  With at least the mapping problem solved, the
      installation headaches would nearly entirely go away, and for
      various common OSes, it would be a natural and simple thing to
      set up GRUB.


--
    Erich Stefan Boleyn     <address@hidden>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"