userspace discovery of partitions

Hi all,

As discussed a while ago (see thread starting at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.2/0659.html), I wrote a frontend to libparted that does nothing but probe all block devices for partition tables, and tells the kernel what partitions it finds. It optionally prints a short summary.

The hope is to be able to remove partition table parsing from the kernel, and share partition table code with libparted.

It's called partprobe, and is distributed with Parted. Get it from:

	ftp.gnu.org/gnu/parted/devel/parted-1.5.6-pre2.tar.gz

When partprobe/libparted are compiled with --enable-discover-only --disable-nls etc (see README), it comes to about 73k (35k compressed), not including libc or libuuid. Unfortunately, this is still quite large to be including in things like initramfs. Is it worth paying this price?

libparted currently supports 7 partition table formats (vs 11 in linux 2.4). It uses the blkpg interface in 2.4 to communicate partition info. (see libparted/linux.c, linux_disk_commit)

Andrew

This would mesh nicely with the filesystem (and other content) probing tool/lib that I wrote, blkid. It probes filesystem types (and also label, uuid, fs size for common fs types).

Hmm, it does seem a bit large for what it is doing. Any idea where the bloat is coming from?

My blkid lib is 34kB (uncompressed) and supports 23 filesystem types (all that the current mount(8) has), although only a handful have full LABEL and UUID support. The user tool is 6.5kB and I also use libuuid.so.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Indeed. To be honest, I think it's a mistake to have both libparted and blkid. OTOH, libparted isn't scaling down very well (yet).

Mainly because the code is structured for editing. Editing is much harder than just reading. There is a lot more information to parse, that you could otherwise throw out. For example, you don't care about partition names, or whether the partition has some magic flag to allow it to boot on architecture X.

Also, since you must provide an incremental editing system when editting, it is often easier to use this system when you are parsing. That means you can't get rid of the editing system when all you want to do is parse. In libparted, this includes a constraint solver (about 7k), code to verify that there's space for metadata, code to set partition types, flags...

In practice, all this code is hard to separate out, and it all adds up. Perhaps this is an argument for maintaining two sets of partition code. Feel free to look at the code, and decide for yourself ;)

Andrew

Nope - I'd much prefer aeb's small partx for the same job :) In fact it can be cut down even more than the current version. which is 30k dynamically linked against glibc. In fact a striped down version wouldn't need a libc so this would be about the size.

It supports dos, solaris, unixware and bsd partitions so far.

Christoph

Of course it doesn't work. We've performed a software upgrade.

If you compile with -Os, and run strip(1), it's 10112 bytes :) (4868 gzipped). About 4k of that is common code.

There is probably enough stuff on an initramfs to warrant a dynamic diet libc?

It looks like a small amount of work to add support for others too. I'm convinced now it's better to maintain both partx and libparted implementations of partition code: one for discovery, one for editing.

OTOH, the "small" version of libparted is still useful for the Hurd, so I'll probably keep this small option for libparted.

Thanks for pointing it out :)
Andrew