Why doesn't GRUB2 load the diskboot.img to address 0x8000 directly?

Question

I'm looking into the source code of GRUB2 and try to understand why the code in boot.S load the diskboot.img (first sector of core.img) to address 0x70000 first, then copy it to 0x8000 using copy_buffer and jump there to continue execution. Why doesn't it load the image to 0x8000 directly?

There's a comment for #define GRUB_BOOT_MACHINE_BUFFER_SEG 0x7000: "The disk buffer MUST be 32K long and cannot straddle a 64K boundary." But the first sector only occupies 512 bytes.

Answer 1

OK, let's formulate this as an answer. I looked at the code and the git history, and this is prehistoric. They are (re)using the same load code in multiple places, and using multiple load codes (dependent on the environment – floppy, disc, LS-120, CD, etc.) to load to the same place (namely, the GRUB_BOOT_MACHINE_BUFFER_SEG).

• Reusing the same code in multiple places may lower the maintenance burden.
• Some of the machine- or media-specific load routines cannot load “just” 512 bytes; they load more (up to 32 KiB; e.g. the CD code always loads multiples of 2048 bytes), and the caller then just copies out how much it needs – optionally, with offset, too.

If you need to know even more, I suggest to contact Vladimir “φ-coder” Serbinenko <phcoder@gmail.com> as the person doing the most work in these areas, and ask him directly; this is all we can “divine” from the code, without asking the authors for the intent.