On Thu, 5 Dec 1996, Scott Reynolds wrote:

> On Thu, 5 Dec 1996, Bill Studenmund wrote:
> 
> > Idea: I've been thinking about increasing the # of partitions too. As I
> > understand it, the amiga port already has gone to 16 partitions! So the
> > problem of kernel code supporting #partitions != 8 has been dealt with.
> 
> I dealt with the technical problems on the mac68k port almost a year ago;
> provided that all access to the disk devices on the i386 is done using the
> DISKPART/DISKUNIT/MAKEDISKDEV macros, things "should" work fine.  (Be
> warned that I don't know how it interacts with the normal BIOS/DOS
> partitioning, though.)  Previously, there were assumptions that the device
> had a 3-bit partition number `field', which is obviously bogus. :-)

Hmm. There's a lot about BIOS interaction I don't know about, but isn't
dos partitioning different from NetBSD partitioning? I don't know.

> > But I've got an idea. The kernel can figure out what it should do. Just
> > have the kernel go out and look on the root file system. /dev/sd1a (or
> > /dev/wd1a or /dev/whatever1a) will tell us the minor # set up. Thus one
> > kernel could boot with either type of system.
> 
> I don't see any reasonable way to implement this without having to modify
> a lot of code.

One question: how much code actually cares? More exactly, how many
different binaries care? Obviously the kernel, and the MAKEDEV script. But
what else? Can disklabel be taught to just try a # of partitions, and let
the kernel complain if there are too many? Don't all other programs just
hand the kernel a vnode pointing to a b/cdev?

For the kernel, would making MAXPARTITIONS a variable instead of a
constant work? Obviously we'd have to initialize the constant to
something, probably 8, but as long as the minor # decoding and encoding
routines agree, there should be no problem.

The one tricky part would be what happens when the # changes. My thought
would be to do it when then only open block device is the root device, and
then have the md code recalculate the rootdevice node # using the new
partitioning.

The one thing I don't know about is how "rootdevice" is mounted. If it
contains a copy of the rootdevice node in its mount (probably does), it'd
need to be unmounted before the change, and then remounted after.

Thougnts?

Take care,

Bill