mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Nicholas Wourms <nwourms@myrealbox.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	linux-kernel@vger.kernel.org, jmorris@intercode.com.au,
	davem@redhat.com, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC] Breaking data compatibility with userspace bz2lib
Date: Fri, 20 Jun 2003 22:51:00 +0200	[thread overview]
Message-ID: <20030620205100.GE22732@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <3EF36E2C.3050906@myrealbox.com>

On Fri, 20 June 2003 16:27:24 -0400, Nicholas Wourms wrote:
> Jeff Garzik wrote:
> >On Fri, Jun 20, 2003 at 08:59:15PM +0200, J?rn Engel wrote:
> >The big question is whether the bzip2 better compression is actually
> >useful in a kernel context?  Patches to do bzip2 for initrd, for
> >example, have been around for ages:
> >
> >	http://gtf.org/garzik/kernel/files/initrd-bzip2-2.2.13-2.patch.gz
> >
> 
> Not to mention the more current ongoing work by Christian Ludwig for 
> 2.4.2x support at:
> 
> http://shepard.kicks-ass.net/~cc/

Hmm, both of them are already behind my work, and I just started this
week. :)

Ok, this isn't fair as I mainly concentrated on the bzlib itself,
jffs2 is likely the easiest user of compression in the kernel.  No
personal offense please.

Jeff didn't copy lib/inflate.c, a horrible hack that has to go, so his
patch is much better from that perspective.  But he kept the bzlib
pretty much verbatim, incl. _WIN32, functions working with FILE* and
so on.  Once you cut all that out, you start to see the real beauty of
the bzlib, it is much nicer than the older zlib.

Still, the blockSize100k part is just plain stupid and should die. 

Oh yes, thanks for the link.  Didn't know that patch.

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham

  reply	other threads:[~2003-06-20 20:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-20 18:59 [RFC] Breaking data compatibility with userspace bzlib Jörn Engel
2003-06-20 19:09 ` Jeff Garzik
2003-06-20 19:45   ` Jörn Engel
2003-06-20 19:48     ` David Lang
2003-06-20 20:05       ` Jörn Engel
2003-06-20 21:53         ` Jeff Garzik
2003-06-20 21:55           ` Jeff Garzik
2003-06-20 20:27   ` [RFC] Breaking data compatibility with userspace bz2lib Nicholas Wourms
2003-06-20 20:51     ` Jörn Engel [this message]
2003-06-20 21:34       ` Jeff Garzik
2003-06-20 19:45 ` [RFC] Breaking data compatibility with userspace bzlib David S. Miller
2003-06-20 19:56   ` Jörn Engel
2003-06-20 20:23     ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030620205100.GE22732@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=davem@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=jgarzik@pobox.com \
    --cc=jmorris@intercode.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nwourms@myrealbox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®