>> If you want to have all initial wedges configured in single user
>> mode, you end up putting knowledge about all types of native
>> partitioning in the kernel,

(Well, no; actually, you need only those that are used by disk packs
that are (or, arguably, might be) attached.)

>> which is exactly the opposite of one of the main points of the
>> wedges proposal.

> This point of the initial proposal is the most controvertial one, I
> think.  [...]  Why do we want to move the partitioning out of the
> kernel?  What do we gain?

You see clearly.  I'd not thought about it in quite that way.

I'm not entirely sure.  On closer examination, most of the things that
come to mind as "benefits" disappear (for example, the ability to do
partitioning from userland: we have this already, I think, though we
have no tool in-tree to read various label formats and install the
resulting partition tables).  The major one that's left is that it
means we don't have duplicated functionality in two places (kernel and
userland).

Other benefits of wedges - such as recursive partitioning - are also
either things we have now (recursive partitioning, for example, which
can be done with single-member ccds) or things that are orthogonal to
moving the partitioning knowledge to userland (scads-o'-partitions
and/or dense minor numbers, depending on which wedge scheme is chosen).

> I've spoken of a daemon as it'd be nice to support removabel media
> [...]. But a daemon could fork off the wedgeconfig program
> (seperating the two).

It could be good to have an interface that allows userland to be
notified on drive appearance or disappearance in general, it seems to
me - or perhaps even just any change in the configured device tree.

> About keeping the disklabel interface: I'm assuming that we're going
> to keep the unit/partition split to device minor numbers (see my post
> yesterday about the problem with just throwing wedges into their own
> major # with minor numbers dictated by allocation history).

We may have to do this.  I'm not entirely convinced it's not possible
to get persistent filesystem device attributes (chmod/chown in
particular) and still get dense minor numbers.

What follows is thoughts and questions, not an attempt to attack an
established position.  I'm trying to find a scheme which gives both
"sides" what they want: both device node assignments stable enough to
preserve chown/chmod info and dense minor numbers.

Across what exactly do you want attributes to remain stable?  Provided
wedgeconfig behaves predictably, dense minors with a single major are
fine provided nothing changes in the disk layout.  Add or remove a
partition, other than such that it will be found at the end of
wedgeconfig's sequence, and you lose.

But you already have something very much like that unless you go to the
trouble to wire down disks in your config file; add or remove a disk -
except at the end of the probe sequence - and the filesystem node
versus partition mapping changes.

Admittedly, adding or removing drives is probably rarer than adding or
removing partitions.  But is it really that much rarer?

Another possibility was suggested by the person who said something
along the lines of

	wd0 at wdc0 ...
	mbr0 at wd0
	msdosfs0 at mbr0 partition 0
	bsdlabel0 at mbr0 partition 2
	ffs0 at bsdlabel0 partition 0
	ffs1 at bsdlabel0 partition 4
	sunlabel0 at bsdlabel0 partition 5
	ffs3 at sunlabel0 partition 0
	swap0 at sunlabel0 partition 1

Given the underlying machinery to create/destroy this sort of thing
dynamically, wedgeconfig could turn into something that would build
this sort of device tree automatically.  As proposed, it has problems,
but it could perhaps mutate into something workable.  As a first cut,
I'd consider making it more like

	wd0 at wdc0 ...
	mbr0 at wd0
	partition0 at mbr0 partition 0 type 0x0b
	bsdlabel0 at mbr0 partition 2 type 0xa9
	partition1 at bsdlabel0 partition 0 type ffs
	partition2 at bsdlabel0 partition 4 type ffs
	partition3 at bsdlabel0 partition 5 type ? # type not checked
	sunlabel0 at partition3 # disk image in this partition
	partition4 at sunlabel0 partition 0 type ffs
	partition5 at sunlabel0 partition 1 type swap

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B