[PATCH 2/2] (g)unzip: Optimize inflate_codes()

[Rob Landley]

On Sunday 14 February 2010 11:04:45 Dan Fandrich wrote:
> On Sat, Feb 13, 2010 at 02:37:06PM -0600, Rob Landley wrote:
> > You earlier mentioned just a straight port of either the zlib or the
> > kernel implementation to busybox, replacing what we've got.  If the
> > current busybox version is measurably inferior, that sounds worth a look.
>
> Why bother with porting zlib into BusyBox in the first place?  zlib is
> already very portable, highly available and has upstream support.  Why not
> just make it an external dependency?  If reducing external dependencies is
> the goal, then you could always keep the old, inefficient code around as a
> fallback.

Wow, you've quite thoroughly missed the entire point of busybox.

There is no "the goal", there are multiple goals that get balanced against 
each other.  Reducing size is a goal, reducing complexity is a goal, reducing 
external dependencies is a goal, reducing the number of separate executables 
in the system (and thus the ELF overhead, filesystem block granularity, mmap 
page granularity, and so on) is a goal...

Busybox doesn't depend on any external libraries (except libc and friends), 
and never has.  We emit raw ansi escape sequences rather than depend on 
ncurses, implement our own command line history in the shell rather than 
getline, and so on.

Keeping "old inefficient code around as a fallback" goes against everything 
busybox stands for.  I personally re-implemented mount at least three times 
trying to get it to do more in less code, and it's since been redone another 
couple times since I left.  I didn't rewrite bunzip because it didn't _work_, 
but because I thought I could do better.

If an existing implementation is good enough (ala dropbear), we simply don't 
put it in busybox at all.  What you're essentially arguing for is the removal 
of gzip, gunzip, zcat, zip, and unzip applets from busybox entirely, since 
there are already usable versions out there from info-zip and friends.  (By 
the way, info-zip doesn't use zlib either, it includes its own implementation 
based on Mark Adler's original reverse engineering of Phil Katz's deflate, I.E. 
zip method 8.  I remembered that from OS/2, and just downloaded the unzip60 
source to confirm.  You could also ask why the Linux kernel doesn't just have 
an external dependency on zlib, since it can be statically linked.)

Now we have previously discussed offering zlib _exports_ from busybox, but 
having a single file contain the ELF bindings to be both an executable and a 
DLL was just too fiddly an abuse of the toolchain for us to bother so far.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds