Quoting Bill Studenmund <wrstuden@netbsd.org>:

> If we're wanting to use it as the kernel side of wedges, we need to do
> something other than refer to "/dev/wd0X" for the source of backing
> blocks. Refering to anything other than the raw partition means we're
> still basing this on partition info, and the point is to move partition
> info out into userland. We also can't refer to the raw partition given the
> current syntax of an offset. The problem with an offset is that it's hard
> (and dangerous) to keep in sync with the partitioning info.

Yes, that's why reading/parsing partition info isn't done by the device 
mapper but by a (possibly userland) library/tool.  There should at least be 
an interface inside the kernel which uses an offset into another device.  If 
we limit this to only raw partitions, then we can't use devices created 
through device mapper as building blocks for other devices.  I see you agree 
to this later.  Also please note that the dmsetup command used in the 
examples from my original mail exposes the kernel interface directly to 
userland and that there are supposed to be more "sophisticated tools".

> What would work is using a partition locator string. The exact format is
> still up in the air, so feel free to comment. But something like, "NDL 4"
> to refer to NetBSD Disklabel partition 4, "APL 5" for Apple Partition Map
> 5, "MBR 0 NDL 2" for partition 2 in the NetBSD disklabel in MBR partition
> 0, or "MBR 3 MBR 2" for an extended MBR partition - partition 2 in the MBR
> in partition 3 of the main MBR.
> 
> The point is to configure based on names/locators for partitions, not
> their locations. That way if another OS repartitions, we don't start
> scribbling on random space.

Ideally partitions should have names ;-)  I use LVM2 from Linux 
as "sophisticated tool" and it gives names to partitions.  

Aren't "MBR 0 NDL 2" and "MBR 3 MBR 2" just names made up from a low-grained 
view of the disk, a fallback when there's no name?  The locator string also 
needs to include the device.  And it should be possible to map the locator 
string into a path to the device nodes which give access to the device.  

Isn't this independent of the device-mapper/libdisklabel issue?  The user of 
libdisklabel has to come up with (and maybe create) a name/path to the device 
node, possibly based on the name stored in the partition.[1]

We could have a device-mapper/libdisklabel based drop-in replacement for the 
partition code in wd/sd/... which uses the names and device nodes we have 
now.  This would run before /etc/rc.d/root and setup the devices.  Maybe 
that's the way to go forward?

> Obviously there would need to be a userland library to read different
> partitioning schemes and supply a list of found partitions that this tool
> would put together into the wedges.

Yes, I think this should move into userland since it's a one-time operation, 
we don't have a dhcp client in the kernel either (but in the bootloader).

-- 
Christian Limpach <chris@pin.lu>

[1] Maybe something like:
/dev/disk0                    [disk raw device]
/dev/pdisk0/part0             [MBR 0]
/dev/pdisk0/ppart0/part2      [MBR 0 NDL 2]
/dev/pdisk0/part3             [MBR 3]
/dev/pdisk0/ppart3/part2      [MBR 3 MBR 2]