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) <[EMAIL PROTECTED]> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
