On Thu, 8 Oct 1998, David Holland wrote:

>  > > 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?
> 
> 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.

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 idea is one which I bounce around from time to time, and would love
to see happen. We just take all the existing readdisklabel routines and
merge them together. :-)

All the drivers care about is that they have a table which says, for this
partition, add thiss offset and don't go beyond this length. The DRIVERS
will be perfectly happy for you to fill this table out how ever you
please.

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. :-)

> A filesystem is a collection of on-disk structure used to split a
> storage system into smaller units (files). This is also what a
> partition table does. Think of the partition table as the combination
> superblock and root directory of a very primitive filesystem.

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

> You can implement all the disklabel handling as a filesystem; then you
> end up with device nodes for just the raw disks (wd0, sd0, sd1, etc.)
> and corresponding directories (wd0p, sd0p, sd1p, etc., where p is for
> partitions) - then you do "mount -tlabel /dev/wd0 /dev/wd0p" to mount
> an instance of the disklabel fs on the mount point wd0p, using the
> block device wd0. Then /dev/wd0p would contain the files 'a b c d e ra
> rb rc rd re' or whatever other canonical representation of the
> partitions present you want. And it could also support altering the
> disklabel on the fly in any of several ways depending on how much
> kernel bloat was tolerable.

Interesting. :-)

How do we mount the root partition in this scheme?

I still think just adding flexability to readdisklabel would get us where
we want to go.

Take care,

Bill