> > Because you end up reimplementing special cases of all the generic
 > > probe and attach code.
 > 
 > I still don't see what you're complaining about.
 > 
 > You do know how disklabels are handeled now, don't you? Each device, in
 > setting the disklabel, calls the readdisklabel routine to actually read
 > the label. This routine is a machine-dependent routine which knows how
 > that machine does things.

Yes. Except that the disklabel structure is not abstracted and all the
disk device structures fondle it. This is bad.

 > You spoke of a library service to handle partitions. Just turn readlabel
 > into such a routine. Make readlabel_mbr, readlabel_macos,
 > readlabel_netbsd, readlabel_sunos routines, and have readlabel try them in
 > (machine specific) order.

This is not quite adequate - this way you still have the partition
*handling* code duplicated in all the disk drivers. And they all know
about struct disklabel, which involves making assumptions about the
nature of partitions that may not be valid in all cases.

 > We'll still need to keep the RAWPART stuff as we want to ignore the
 > partition table for that partition. That way we can always read the
 > partition table off the disk. :-)

This is part of the problem, not part of the solution - done properly,
the partitions should be a layer on top of the raw disk. Having a
pass-through partition is a hack.

 > Given that definition, I see your point. Though I really want more from a
 > filesystem than a partition map can offer. :-)

Not suggesting to replace ffs with labelfs. :-)

 > How do we mount the root partition in this scheme?

Yeah, see, this is a bit of a problem. But it's solvable - basically
you need to provide a back way in to the labelfs mount stuff for the
root disk that hands back a dev_t for mounting root, and then another
back way in to complete mounting that labelfs. Not the greatest, I
admit. 

There are a number of other cleaner ways to solve this problem, but
all the ones I can think of involve a certain amount of redesign of
mounts or the vnode interface or both.

-- 
   - David A. Holland             | (please continue to send non-list mail to
     dholland@cs.utoronto.ca      | dholland@hcs.harvard.edu. yes, I moved.)