Oops. I don't know if I sent this or not...

On Fri, 11 Aug 2000, Bob Nestor wrote:

> Bill Studenmund wrote:
> 
> We don't currently define all the areas of the A/UX extension of the map 
> entry in our disklabel header.  When I did the sysinst/mac68k code I 
> included the missing definitions and used some of them to store values 
> during partitioning.  While it's not absolutely necessary that we 
> preserve these areas for sysinst use, it might be nice. ;-)

Even if we don't use them, we should include them in the definition just
for compatability. Hmmm... macppc's disklabel.h includes some of these
fields.

> The areas remaining in the A/UX extension that I didn't use are:
>    the 8-bit cluster size
>    the 16-bit inode bad block number
>    the 8-bit unused/undefined part of the flags word
>    the 5-bit slice number in the flags word, although this would be nice 
>		 for OS type
>            such that various BSD type systems could distinguish their 
>		 partitions
>    the three 32-bit time fields reserved for FS creation, mount and 
>		 umount time.
>           These might be good for block, fragment and Cyliner/group values
>    none of the abm or filler reserved for the abm

I hope I indented that right.

> NetBSD and/or sysinst/mac68k currently uses:
>    the magic, type and root/usr/crit/part of the flags word and the 
> mount_point name

??

> >There are two ways we could do this. One would be to make NetBSD_LFS,
> >NetBSD_CCD, and NetBSD_RAID partition names. Another would be to add one
> >new NetBSD partition type, and have the partition type code stored in
> >there.
> 
> We could just extend the meaning of the type field.  Right now only the 
> first three values are defined: 1 =>Std FS; 2=>Autorecovery (not used); 
> 3=>SWAP.  This is an 8-bit field so we have 253 values not yet defined.

Except for SWAP, none of the fs types which make sense overlap these. My
only concern is if anyone else has extended the type codes. We could also
add a flag saying we have used our own type code here too. :-)

> However, I'd like to propose that we define a new structure that we tuck 
> into the area reserved for ABM expansion.  This area contains room for 7 
> 32-bit words and should be more that enough for what we need.  That way 
> if anyone or anything chooses to use the other already defined fields 
> that we don't we shouldn't have any conflicts.  If we feel we need more 
> room we could take the three 32-bit words currently reserved for the abm 
> itself giving us a total of 10 contiguous words.

Where is the stuff reserved for ABM expansion documented?

Take care,

Bill