Subject: Re: Partition tables (was: Re: Another changer, another changer problem)
To: None <>
From: David Holland <>
List: current-users
Date: 10/07/1998 18:45:57
 > > Disklabels and partition tables should be an abstract kernel service.
 > > The way this stuff is munged into all the disk drivers right now is
 > > really pretty disgusting.
 > Indeed.

Glad I'm not the only one who thinks so. :-)

 > > It would also cut way down on code duplication in the disk drivers.
 > This is one of the ugly parts alright where a wee bit more layering
 > would definitely make things easier to understand, easier to modify, and
 > probably a lot more elegant (and reliable).
 > A quick grep for "= RAW_PART" in the kernel source gives a good
 > indication of just how widely spread this disease is.  Making partition
 > table handling a core part of the kernel instead of a function of every
 > disk driver is a big project for sure!

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.

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. 

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.

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.

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.

   - David A. Holland             | (please continue to send non-list mail to      | yes, I moved.)