Re: El Torito, odd floppies 0.92 working patches...

[Thierry Laronde]

On Thu, May 02, 2002 at 04:52:12AM +0900, Yoshinori K. Okuji wrote:
> Thierry, I have some questions.
> 
> At Wed, 1 May 2002 19:58:15 +0200,
> Thierry Laronde wrote:
> > - booting from CDROM
> 
> Great.
> 
> > - booting from odd floppies format
> 
> Ditto.
> 
> > - Position independant stage1 (allowing to load another stage1 like a MS
> >   classical MBR or another GRUB stage1 --- on another drive for example)
> 
> Where is this useful? Maybe my imagination is too poor.

There have been some report about grub not working _chainloaded_ by some
alien bootloader (this was the only common point between different
situations). I had supposed that a problem should be that MS, which
doesn't care at all about other system, chainloads a sector at another
address than 0x0:0x7C00 (easy trick to make other fail). With PIC code 
we don't care anymore.

Secondly a). Suppose one wants to have one disk plus several removable disks, 
where the disks are not mirrors of each other. Allowing stage1 to load another
instance of itself (you can load a sector at 0x0:0x7c00 with this new
stage1, since it is PIC _and_ relocates itself) will allow to have a MBR 
able to load another MBR on another disk giving access to whatever choices 
are on the disk actually inserted.

Secondly b). For someone having an old PC with a BIOS unable to boot
from a second drive, where the second drive is a removable one (you have
racks), you can use GRUB as the MBR in the first drive to load the MBR
of the second disk (the MBR being the only well known and unchanged
place where to find sectors of a bootloader).

Third. For distributions, this stage1 can be patched to load a
previously installed sector (say the first of a MS partition). This is a
supplementary trick to restore the previous situation.

Fourth (more or less linked to third). Our MBR is now more or less
independant from GRUB. It can be used to load other bootloaders
directly.

> 
> > I have kept the include/arch-i386 new tree, but restored stage1 and grub
> > (renamed grub-shell in a previous attempt). I think this should be a
> > good compromise: only my new headers are in a new directory.
> 
> Why do you call it "compromise"? At the time when I and you talked
> about new stage1, you didn't say anything about the reconstruction,
> IIRC. Would you mind telling me what had you to stick to your revised
> structure?

Because since the discussion, I have actually worked on the code. And
every time I encountered values, remembering too the discussions about ia32
specificities, I had logically to create separate headers. Adding arch
dependances simply helped me to more correctly code the stuff, and this
is just a matter of _one_ directory. The `include' directory is, IMHO,
mandatory.
Secondly, since I have 3 months of delay, I prefer coding once the
"correct" way than having to retouch the stuff in some months. God only
knows how much delay I will have the next time if there is one. I hope,
after beta debugging, that stage1 will remain untouched for some
months/years... Because, if now I have, well, more than a good overview
about the initial steps of GRUB loading, I think people will continue to
deal with more "higher" level stuff. I try to avoid the necessity for
others to dive in the code to understand how it works.

I call it compromise, not compromise between you and me, compromise
between tagging all the stage1 stuff with arch dependances, and keeping
a directory tree that will not break previous installation scripts for
example.

In brief: this is cleaner. For example the
"include/arch-i386/boot_abi.h" is definitively a correct way to avoid
mistakes (for example, when modifying start.S, I first suppress loading %ebp
with the install_sector, since I didn't see it used anywhere; and when I
switch to asm.S, I saw and remembered that this was used for
`save_default': this was not mentionned explicitly; this shows too the
superiority of literate programming IMHO. Even with tons of comments,
the logical structure of the program is spoilt by the mandatory structure
of the source --- different pieces of the code, spread away from each
other in the source, are intimately linked logically).


Regards,
-- 
Thierry Laronde (Alceste) <address@hidden>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C