From: drew@ophelia.cs.colorado.edu (Drew Eckhardt) Subject: Re: FAQ-finding mission 1: boot techniques Date: 24 Jun 1992 18:22:23 GMT
In article <1992Jun23.174127.29205@bernina.ethz.ch> almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
>In article <1992Jun22.042513.13197@muddcs.claremont.edu> jwinstea@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>> Shoelace is dependent on the Minix filesystem, I believe, so I hope
>> someone plans on making available an update for the new Linux
>> filesystem, once it becomes available.
>
>How about a generic boot loader ? It could get the absolute positions of
>the sectors from a running kernel (1) and create a mapping table. The
>boot loader could read that table (2) and load the kernel (3) without
>even knowing what a file system is.
>
>Minor disadvantage: there'd be one additional step after copying a new
>kernel image to /linux or whatever: re-creation of the mapping table.
>
>Problems:
> (1) this needs an interface to bmap (trivial) and a way to get a) the
> disk geometry and b) the partition information (starting sector of
> a given hd?? device). a) is already there for non-SCSI disks
> (HDIO_REQ). The rest would need some merging of partition handling
> of hd.c and the SCSI stuff. (But that'd be a good idea anyway.)
The SCSI partition table is readable, just like on any other
device. You can be sure that the starting sector is accurate,
however the other information is bunk. In fact, the SCSI
routines ignore it completely.
As far as merging partition handling in hd.c and the SCSI driver :
It will happen.
> (2) is it correct to assume that the boot disk is always identified
> as 0x80 to the BIOS ? SCSI disks might add problems here, but I'm
> not sure.
The active partition is marked like this. However, if you use a
different master boot block (ie Winiboot), this isn't
nevessarily the case.
> (3) better: load either the default kernel or one of, say, four
> kernels (including the default kernel), just like shoelace does
> it.
Not one of four. Simply implement a "normal" boot monitor
program, where you can boot any file off of any device if
some one spacebars, if not boot /vmunix.
> (4) should the table contain sector addresses (sec,head,cyl) or block
> numbers ? I'd prefer sector addresses because that removes all
> computations from the boot loader.
>
block numbers. Sector addresses do not exist for SCSI disks,
sector numbers are also smaller than the 3d coordinates
that map to them, and the conversion between
s/h/c and absolute sector number is trivial.