> 1.  It's my understanding that the area protected by RF_PROTECTEDSECTORS is
> designed to include such things as the physical disklabel, any boot
> strapping code that might reside on the physical disk, and the raid
> component label itself.  Thiss would imply that disklabel -r sd0 or wd0
> should read the label out of this protected region, assuming the raid
> partition includes the entire disk.  Is this right?

Effectively it is the data used by the raid system to work out the layout
of the raid.  Like any other (sensible) filesystem, the first 8k is
reserved for boot code.

> 2.  It looks to me like most of the boot loaders work in such a way that
> the first stage loader has the block numbers of the second stage loader
> hard coded into them, meaning that the second stage loader could be loaded
> from any portion of the disk, including the first portion of an ffs
> filesystem inside a raid-1 partition.

Some do, some actually understand the filesystem layout (this makes is
much less error prone, and gives you the ability to boot from filesystem
types where the file blocks aren't constant).
The new i386 code reads the filesystem, 8kb is plenty of space for this
code - however I need to rewrite the filesystem code to use less buffers
(you can't fit enough 32k buffers into 64k of memory!).

> Once the second stage loader is
> loaded, I believe space and code constraints are sufficiently removed, that
> the second stage loader could properly locate a kernel inside a raid-1 set
> or a physical disk directly -- no?  If this is so, then it strikes me as
> easier to teach the second stage boot loader how to locate a kernel either
> in an FFS filesystem in a raid-1 set or in an FFS filesystem in a physical
> partition.

This already happens, it looks at the partition type in the netbsd disklabel,
it it is 'raid' then it adds 64 to all the sector numbers.

	David

-- 
David Laight: david@l8s.co.uk