Subject: Re: partition bookkeeping
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/27/1999 12:20:02
On Sun, 26 Sep 1999, der Mouse wrote:
> I think the biggest lose with device majors and unit/partition minors
> (ie, the current major/minor scheme, more or less) is that I can't see
> how to do recursive partitioning, except with something like ccds.
Oh, we do the recursive, find all the partitions trick of the wedge
proposal, we just only asign them to the 64 minors for that drive.
Here's how I see recursive partitioning within the unit/partition minors:
First off, the only parttiioning scheme right now which supports recursive
partitioning that I know of is mbr (which needs it as mbr only supports 4
I've spoken of a library with routines which read each different
partitioning scheme. When invoked, it would be passed info pointing to the
disk in question, an offset into the disk, and the minor # of the first
available partition. At first, the disk offset is 0 and the partition
number is 1, for partition a, but since we can recurse, these numbers
might be different.
So this is what the mbr-reading routine would do:
It would look at the 4 mbr partitions, and prioritize them. The priority
would be: NetBSD mbr, FreeBSD/386BSD mbr, OpenBSD mbr, other, recursive (I
think only the "Extended" partition does this). If any of the 3 *BSD mbr
partitions are found, 8 partitions are grabbed and a netbsd-disklabel-
in-partition routine is called which extracts the disklabel info into
these partitions. 8 partitions are grabbed so that changing the number of
partitions used in the disklabel doesn't shift the minor #'s which follow.
Other mbr partition types are each given a partition.
Then we recurse, calling this routine with the offset of the extened
partition and the number of the next free partition entry.
The big thing is that for mbr-using setups, you'd get the exact same first
8 partitions (a -> h) with this scheme as before. :-)
And since all the routine is passed is an offset into the disk and the
number of the first free partition (actually its address would be better),
it's easy to chain them. We just keep calling each reader routine on
whatever list we have until we've exhausted the list. Each one which is
found would add its partitions on the end.
For instance, Zip Tools cartridges come with both MacOS and mbr partitions
on them. With this idea, both the mbr and MacOS reader routines would be
called, and could find the respective partitions. :-)