In message <20021216010324.GC264@drowsy.duskware.de>Martin Husemann writes
>On Sun, Dec 15, 2002 at 04:49:17PM -0800, Jonathan Stone wrote:

>It's there because (MBR-) slices didn't cut it, at least if you are not only
>looking at i386 and MBR.

Martin,

I think we're talking at cross-purposes.

I am *not*, repeat *not* proposing anything that conflicts with any
any ``wedges'' implementation, where wedges _require_ a userspace
daemon to discover and mount filesystems.

I see two quite distinct usage modes for having better
slice/wedge/disk-partition handling in NetBSD. 

#1: supporting more native NetBSD partitions than will fit,
    comfortably, in any reasonably-sized Netbsde-native disklabel.

#2: providing _reasonable_ support for NetBSD and other Oses co-existing
    on a single physical disk, where the NetBSD installation mounts
    filesystems from those other OSes.  (Linux, FreeBSD, O***bsd, Darwin,
    Windows, other wholly-separate copies of NetBSD; whatever).

I'm firmly in the second category (I've not had cause to use#1; see
what Bill said about fragenting free space across partitions).

If you look back to when Charles originally floated the ``wedges''
idea, I think you'll find that ``slices'' (as provided in the FreeBSD
implementation) are a strict subset of ``wedges'': wedges are just
slices, with the exceptino that you can recursively nest one or more
`wedges' inside another wedge.

I think we can get both short-term and long-term wins, *and* clean
code, by doing an in-kernel implementation of the non-recursive
(``slices'') subset first[*]; and then exploring the (currently-unknown)
territory of arbitrarily-recursive ``wedges''.

I also think a kernel-only subset that handles such common cases, is
firmly in keeping with NetBSD tradition and precedent. Maybe thats just me.


[*] Reading toplevel vendor-native labels, plus MBR format (where
different), since MBRs have won hands-down as exchange media for consumer
electronics.