On Wed, May 13, 2009 at 11:18, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, May 12, 2009 at 04:28:06PM +0200, Karel Zak wrote: > http://marc.info/?l=linux-scsi&r=1&b=200904&w=2 for the start of the > patch series. Still doesn't do dm, but even one it does we still do > need a fallback for older kernels. I don't really see a way around > calling dmsetup for now. Maybe we could directly issue the dm ioctls, > but I'm not sure it's a that good idea either. Sounds like libdevmapper? > Cfdisk shows the filesystem type, which I think is a really neat > feature, it does howerver currently not detection e.g. LVM volumes. So > switching all this to a common backend would be really nice. > (Did I mention I really love the cfdisk interface? :)) I like that too, and think it's very useful to see more than just numbers, to prevent to do the wrong thing while changing partition information. > Last but not least partition table reading is very little code, and > showing that into a shared library of it's own is a bit revolting. > Either we have a libfdisk or whatever doing both reading and writing, > or we have the partition table detection (and reading is not much more > than detecting and reading out a few fields) into the library we use > for all the other detection. Yeah, if it fits in any way in the libblkid API, I like to see the partition probing code there. We need the partition table information in many cases along with the filesystem type, to see things like the raid flag, the hidden marker, ... The writing and mangling of partition tables can probably go into its own library, it's a very different task from probing. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
