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.

??

Take care,

Bill