busybox and mkfs.xfs

[Rob Landley]

On Thursday 13 July 2006 5:24 am, Michael Hunold wrote:
> Here are the results for my local busybox configuration, using gcc 4.0.3
> cross toolchain on MIPS.
>
> - busybox static (no xfs): 253628 bytes
> - busybox static with xfs: 586188 bytes
>
> So mkfs.xfs enlarges busybox static binary by 332560 bytes.
>
> - busybox shared (no xfs): 187572 bytes
> - busybox shared with xfs: 535424 bytes

That's not going in. :)

> A naive comparision for the static binaries: when xfs enlarges busybox
> by 332560 bytes and the standalone application is 411776 bytes, then
> integrating it into busybox saves 79216 bytes.

Yes, it does.  It's still way too big to go in.

> I think that busybox's philosophy is to rewrite things to make it space
> and memory efficient in order to achieve maximum savings.

Yup.

> I read about the controversy with e2fsprogs and if merely integrating
> alien source code into busybox should be done at all.

It should not.  It wasn't under Erik, and my threshold for new features is 
higher than Erik's.  This may have something to do with the fact that Erik 
got us to 1.0, and I've done all the releases since 1.0 even before I was 
actually maintainer.  After a project hits 1.0, it pretty much by definition 
has all the features it actually _needs_, and at that point it's best to 
say "no" to new features unless there's a good enough reason to say yes.

Unfortunately, uClibc and BusyBox share an svn tree and some uClibc developers 
believe that access equals permission, even after they've proved they have no 
taste and tell the maintainer he's "standing in the way of progress" by 
objecting to the quality of code that gets added, such as the e2fsprogs 
directory...

My personal rule of thumb is that I'm trying to keep the size of the 
dynamically linked defconfig x86 binary under one megabyte.  Adding new 
features means shrinking something else to make room.  I'm currently 
rewriting mke2fs from scratch to get one that doesn't suck so much.  (Because 
it bothered me enough to bubble to the top of my todo list.)

> Please tell me what you think.

I'm not against the idea of mkfs.xfs being added to busybox, but there's no 
possible excuse for a program that just writes empty structures to disk being 
even 100k, let alone over 300k.  (I could almost understand an xfschk being 
that big since it's potentially doing something complicated, but I still 
wouldn't want it in BusyBox.)

Yes it's smaller being in busybox than standalone, but that's not the only 
threshold a program has to get past in a post-1.0 BusyBox.

Rob

P.S.  I just noticed you're talking mips binaries, which are naturally bloated 
by a factor of 3 so I'm probably overreacting to the binary size a bit.  But 
it's still way too big.
-- 
Never bet against the cheap plastic solution.