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
On Jan 02, 2002 05:57 +1100, Andrew Clausen wrote:
> 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.
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).
> 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?
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/
On Tue, Jan 01, 2002 at 01:18:17PM -0700, Andreas Dilger wrote:
> On Jan 02, 2002 05:57 +1100, Andrew Clausen wrote:
> > 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.
>
> 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).
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).
> Hmm, it does seem a bit large for what it is doing. Any idea where
> the bloat is coming from?
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
On Wed, Jan 02, 2002 at 05:57:35AM +1100, Andrew Clausen wrote:
> 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?
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.
On Wed, Jan 02, 2002 at 08:34:38PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 02, 2002 at 05:57:35AM +1100, Andrew Clausen wrote:
> > 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?
>
> 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.
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 supports dos, solaris, unixware and bsd partitions so far.
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