[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Details on blocklist in stage2/stage1_5
From: |
Thierry Laronde |
Subject: |
Re: Details on blocklist in stage2/stage1_5 |
Date: |
Thu, 20 Jun 2002 19:48:02 +0200 |
User-agent: |
Mutt/1.2.5i |
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