Re: CVS commit: src/sbin/disklabel

[David Laight <david%l8s.co.uk@localhost>]

On Wed, May 15, 2013 at 09:48:03AM +0900, tsugutomo.enami%jp.sony.com@localhost 
wrote:
> Christos Zoulas <christos%astron.com@localhost> writes:
> 
> > Are you worried about efficiency here? Yes, you can fix it differently 
> > by checking if LABEL_OFFSET fits.
> 
> I don't worry about efficiency.
> 
> I've just noticed build failure on i386, and wondering what was wrong.
> 
> I thought it would be better if warned when LABEL_OFFSET exceeds
> bootarea_len, but strictly speaking it is different matter.

I remember there being 2 main constraints:
1) Everything has to fit in the first 8k of the disk.
2) The netbsd label must not cross a 512 byte boundary.

The second constraint stopped a lot of architectures have a the default
number of partitins increased.

One problem is that non-boot media and exchangeable media need to be
read by different sustems that have different LABEL_SECTOR and
LABEL_OFFSET. I don't remember there being a was of deterimining
how much space was allocated on a volume for the label.
The 'partition count' is used to mean 'the number of fields with
values in them', possibly the checksum could be used (assuming that
any zeros can be over written).

Then there is the issue of 'c' and 'd'.
The x86 kernel sets the in memory 'c' and 'd' based on the disk size (etc)
regardless of the disklabel contents.
The 'c' partition info is almost never used (I think it is/was used to
determine the label secton that can't be written to).
If you put a disk where 'c' is raw, and 'd' is u user partition into an x86
system the 'd' partition could be made available as wd0c!


        David

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