Subject: Re: Partition tables (was: Re: Another changer, another changer problem)
To: David Holland <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 10/07/1998 16:39:54
On Wed, 7 Oct 1998, David Holland wrote:
> Yeah. The vague plan I had was to first build the new services,
> layering them on top of the raw partition provided by the existing
> drivers, then, once that was working, starting to rip cruft out of the
> drivers themselves.
> The chief design question, I think, is how to do minor/major number
> handling and how this interacts with bdevsw and device attachment. I'm
> not entirely convinced it'll all work and keep backwards compatibility
> with installed /devs without some ugly hacks.
It should. :-)
> If you keep the same device numbering, you get multiple entries for
> the partition driver in bdevsw and horrors in softc handling inside
> the driver.
Same device numbering?
> On the other hand, if you use a new major number for the partition
> driver, then you limit yourself to 256 partitions on the system until
> dev_t becomes 32 bits wide. (Or is it now?) And you have horrors
> trying to figure out which partitions belong to which disks.
dev_t has been 320bits wide for years. The major and minor routines were
taught how to use all 32-bits about 6 months ago.
I think the cleanest thing to do is to just make the unit and part macros
use a different seperation for major units over 255, have two entries in
b/cdevsw, and have a canonicalization routine in the driver or in specfs
(take a given device number and turn it into the one for the
higher-numbered device - oops, either this happens in the driver, or we
add info to b/cdevsw. Easy either way).
Then you have a system which can live with 32 or 64 partitions easily, and
is backwards compatable with current devnodes.
> A third option is to leave the numbers alone and have the disk drivers
> call out into a partition table library of some kind, but then you get
> probe/attach horrors.
?? Why do you get probe horrors?
> You can also treat the partition stuff as a (simple) filesystem
> instead of a device driver; in some ways I think this is the best
> approach... but it causes some real horrors with compatibility.