Subject: Re: "sector range" driver (was Re: APPLE_UFS on i386?)
To: Bill Studenmund <email@example.com>
From: Christian Limpach <firstname.lastname@example.org>
Date: 03/29/2003 22:20:53
Quoting Bill Studenmund <email@example.com>:
> 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.
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 <firstname.lastname@example.org>
 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]