no no no. Not -that- heavyweight.
Partition support becomes a -peer- of LVM.
Imagine a tiny blkdev driver that understood MS-DOS (and other) hardware
partitions, and exported N block devices, representing the underlying
device (whatever it is). In fact, that might be even a -unifying-
factor: this tiny blkdev module -is- your /dev/disk. For example,
/dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
/dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
A nice side effect: modular partition support, since its a normal
blkdev just like anything yes.
YES there is overhead, but if partitions are just another remapping
blkdev, you get all this stuff for free.
I do grant you that an offset at bh submit time is faster, but IMHO
partitions -not- as a remapping blkdev are an ugly special case.
Remapping to an unchanging offset in the make_request_fn can be fast,
too...
-- Jeff Garzik | "Are you the police?" Building 1024 | "No, ma'am. We're musicians." MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/