Re: Details on blocklist in stage2/stage1_5

[Thierry Laronde]

Hello,

On Thu, Jun 20, 2002 at 10:51:04AM -0600, Jason Ivey wrote:
> Bill, Okuji,
> 
> I didn't want to start any debates over this.  PowerQuest was just under
> the impression that as found in the documentation there are a number of
> well defined variables that we could manipulate.  We have no grand
> illusions that these locations and even the implementation of the logic
> will remain constant throughout the lifetime of GRUB.  Keeping up to
> speed with Microsoft and NTFS without documentation and without source
> is something we are accustomed to and have come to expect that with
> every new release something will break our functionality.

OK, since I wrote a new version of the stage1 and I think Okuji is about
to add it to the official source, here are some hints.

Things that may likely not change in a near future if the new stage1 is
used (since size optimizations imply to use this very place):

Identification of the GRUB and boot abi version (MBR/first sector):

system_id: /* offset 03h */
        .ascii  "GRUB " /* exactly 5 bytes */
        .byte   COMPAT_VERSION  /* + 1 byte */
        .byte   STAGE1_VERSION  /* + 1 byte */
        .byte   0       /* +1 byte = 8 bytes */
                                
The COMPAT_VERSION identifies GRUB boot abi.
STAGE1_VERSION can be ignored for that purpose: it is *only* the
revision version of stage1.

In stage1 too is the crucial info about the first sector (of stage2 or
stage1_5 that is in fact start.S) to load. It is, in the new version, at 
offset:
---- in stage1/stage1.h
/* The offset of STAGE2_SECTOR.  */
#define STAGE1_STAGE2_SECTOR_OFFSET     0x32

---- in stage1/stage1.S
stage2_sector:
        .long   1
        
These are unlikely to change too. For stage2/start.S which is the first
sector of stage2/1_5 the structure MAY change but not in the very next
days...

What I have in mind for the remaining parts (to have an easy way to
identify what infos need to be changed) --- and that we haven't
discussed so far --- is to create fake (I mean possibly unused) C
headers files exposing the boot info structures, so that one can have a
simple way to update tools having to manipulate this. This MAY be used
too, internally by the GRUB, for booting OSes. So there will be a
running time info (multiboot) and a compile time infos: the headers. The
idea is to change for us the `boot' command so that filling up the
correct structures for OSes will allow us to update more easily (having
too perhaps a way to feed GRUB with this at running time via the
`script' abilities (menu)).

If the developers have some suggestions about the kind of structures,
there are welcome (possibly in private).

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