[Leo Weppelman]

> From both the proposal mail-archive that was put on the net by Frank
> and the discussion following it, I concluded/interpreted the
> following:

>   * The kernel builds the wedge device for the root filesystem.

Check.  Not much choice about this.

>     This means that at least one of the various partitioning types
>     must be supported by the kernel.

No.  It's entirely possible that the bootblocks could pass the kernel a
<device,offset,size> triple good enough to build a wedge for the boot
partition without needing to understand any partitioning scheme.

Of course, if the root partition isn't the same as the boot partition,
or if the bootblocks can't do this for some reason, yes, the kernel
does have to have some minimal partitioning smarts.

>   * It is a bit unclear when wedge info is destroyed.  Must this be
>     done explicitely (per disk device, per wedge)?  Will media change
>     be detected by the wedge driver?

It seems to me that a wedge device can be destroyed in two ways:

+ Explicitly, as by wedgeconfig when run to repartition a disk.

+ Implicitly, by destroying the real device underlying it (removing a
   PCMCIA card or scsictl detach - if scsictl detach ever makes it in).

>   * We have to figure out a naming [scheme].  [...]  Whatever, I
>     personally think that there must be a link between the
>     <driver><instance><partition> (ie. sd1a) and the wedge name.

I'm not entirely sure the wedges have to have names in their own right,
except in the sense that they have to have some kind of namespace in
order for wedgeconfig to manipulate them.  I'm not convinced they need
to exist in /dev, for example.

[Bill Studenmund]

> [A] couple of people (myself included) really don't like the idea [of
> having the bootblocks pass in wedge info as I described above] as we
> then need a daemon to fire up in single user in order to be able to
> fsck more than the root filesystem.

Not necessarily a daemon; I see no reason why wedgeconfig couldn't run
once, load its info into the wedge driver, and then go away.

Admittedly, to people used to partitioning being entirely in-kernel,
this will be a potentially nasty shock.  If it's not too much pain, I
think Bill is right (in text I snipped); it would be good to be able to
compile support for one or more partitioning schemes into the kernel.

> All we really need to do is delete readdisklabel and setdisklabel as
> MD routines and totally kill writedisklabel (as userland tools do
> this now).  We then make readdisklabel and setdisklabel the front
> ends to the wedge system.  We can change the names to remove
> disklabel if we wish. :-)

This *does* require a userland daemon.  It also sticks with making
wedges part of the disk drivers, rather than devices in their own
right, and thus runs into the raw-partition question.  I don't see
what's wrong with giving the wedge devices their own major number; it
makes sub-partitioning a whole lot simpler, completely nukes the
question of how many partitions a device can be shattered into, and
just generally simplifies the conceptual framework.

Of course, most of these decisions will end up being made in favor of
the choice preferred by whoever sits down and implements something. :)

					der Mouse

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