On Wed, 22 Sep 1999, Frank van der Linden wrote:

> On Tue, Sep 21, 1999 at 04:33:24PM -0400, der Mouse wrote:
> > Yeah...but I still don't see any need for a "raw partition" with
> > wedges.  Just access the underlying device directly rather than doing
> > anything with the wedge partition devices.

So you're sugegsting that the major number for the wedges will not be the
same as the major number for the device itself? That's not something I
took out of the initial wedge proposal, and is something I'd object to. 
While the major numbers for the devices with wedges will be different from
our current major numbers for the same type of device, I think the major
number for the wedges should be the same as for the device. 

Given that, the minor number for the whole-disk has to be one of the minor
numbers for the drive. :-) Given that, having a "whole disk" partition or
not in the in-core disklabel or the wedge bookkeeping structure (see
below) is just whether or not there's an entry for that minor number in
the table.  Given that it sounds best for the whole-disk minor number to
be 0 (I changed my mind from yesterday & agree with Leo), I'd say it's
easier to have that entry exist than to not (otherwise we always have to
subtract 1 from the minor # to get the table entry). 

> Exactly, yes. Remember, with wedges you're not talking about
> "disklabels" anymore, you're talking about some wedge-bookkeeping
> structure for a disk, which should contain *no* knowledge itself
> about what a "raw" device is. The basic "raw" device is the whole
> disk. If you want to access partitions in a "raw" fashion, then you
> just need to configure a wedge to contain the whole partition.

The wedge-bookkeeping structure you talk about above is the same thing as
the in-core disklabel Leo was talking about. They both map minor numbers
to offsets & valid sizes. And one of the points of what Leo was
suggesting about the in-core disklabel is that it doesn't correspond to
the on-disk disklabel. So it's the same thing as what you're talking
about, just with a less radical name. :-)

Also, I think your last sentance is reflecting an MBR-centric view. :-) In
the mac side of things (MacOS partitioned disks), we shove one filesystem
onto each partition, not a NetBSD disklabel struct which divides things
up. :-) So there's no difference between what we want/get and "the whole
partition." :-)

> The knowledge of the underlying partitioning scheme (which is
> strictly MD) would be in 1) an MD corner of the kernel which deals
> with creating an initial wedge configuration in order to find the
> root partition and 2) the wedgeconfig user program. The wedgeconfig
> user program would ideally know about all partitioning schemes,
> because it would enable you, for example (together with FFS 
> byteswapping) mount a disk from another NetBSD architecture
> without any problems. Or from any other system whose file systems
> we support. The kernel doesn't need to know about it, you just
> let the userspace code figure it out, calculate the boundaries,
> and push them into wedges.

While Leo didn't spend time talking much about a userland daemon, the
sticky bit in the in-core disklabel makes everything you describe above
possible. :-)

The kernel bits really are the same. :-) They both have the in-kernel
minor number-> offset mapping no longer corresponding 1 to 1 with an
on-disk disklabel. They both can be loaded by a userland daemon and be
persistent. They both can be loaded by an in-kernel routine from on-disk
info. The terms are different, as are a few of the details, but the
principle workings get us to the same place. ;-)

The one thing I didn't like about the wedge proposal is it handed a lot
off to the userland daemon. I'd like to be able to configure into the
kernel support for a few different partitioning scheme readers into the
kernel. So for instance in single-user mode, NetBSD-partitioned and
MacOS-partitioned disks all come up correctly. But that shouldn't be too
hard with a framework for multiple partitioning scheme -> in-core label
readers in place. ;-)

> Now, what should be discussed (and has been) is a naming scheme
> for device nodes. It's a good opportunity to get rid of
> the mess that is wd/sd naming, 'c' or 'd' for the name of the
> "raw" disk device, etc.

As above, I vote we loose both c and d as the specially-handled whole-disk
partition (so everyone else knows, right now the whole-disk partition gets
no bounds checking in the disk drivers). I think it'd be good to keep
partition c being the whole disk or MBR partition when dealing with
disklabeled systems, but that could be more of a convention than the
special case it is now.

I think we should only move away from sd & wd names when we merge the
drivers together. i.e. the names should reflect the driver entry points.
If the entry points are merged, then so should the names. ;-)

Take care,

Bill