Subject: Re: will the real maxpartitions please stand up?
To: Chapman Flack <flack@cerias.purdue.edu>
From: Frederick Bruckman <fredb@immanent.net>
List: port-i386
Date: 08/29/2004 14:00:00
In article <200408271649.i7RGnQj5021388@basm.cerias.purdue.edu>,
	flack@cerias.purdue.edu (Chapman Flack) writes:
> How come /sys/arch/i386/include/disklabel.h says:
> 
>   #define	MAXPARTITIONS		16	/* number of partitions */
> 
> but /sys/arch/i386/conf/files.i386 says:
> 
>   maxpartitions 8
> 
> ?
> 
> I noticed it in 1.6.2 but the CVS HEAD is that way too.
> 
> The maxpartitions in files.i386 seems to be used only internally by config
> to do some name <-> maj,min mapping.  If there's some trick involved and
> these two values really need to be different, there probably should be
> comments in both places explaining what the trick is and how many
> partitions it's really safe to use and why.

i386 has supported 16 partitions since before NetBSD 1.6. If you're editing
a disklabel created by 1.5.3 or older, you have to change the "N partitions"
field in the disklabel to "16" to use i-p, else the entries will be ignored.

The change is noted in the "Changes from 1.5 to 1.6" section of the CHANGES
file, at least.

The trick you noticed, was so that the device file "/dev/sd1a" (and others)
would not suddenly become useless after a kernel upgrade. (That device file
would point to the actual partion "sd0i".) Nowadays we might train "rc.d" to
fix it up at first boot, but "rc.d" was new, then. There was much discussion,
and transparency to users finally won out over elegance.

-- 
Frederick