From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: linux-kernel@vger.kernel.org
Cc: jmorris@intercode.com.au, davem@redhat.com,
David Woodhouse <dwmw2@infradead.org>
Subject: [RFC] Breaking data compatibility with userspace bzlib
Date: Fri, 20 Jun 2003 20:59:15 +0200 [thread overview]
Message-ID: <20030620185915.GD28711@wohnheim.fh-wedel.de> (raw)
Hi!
I'm almost finished with adding bzlib support to the kernel. You
could also say, I'm already 150% finished, as there is only cleanup
left to do. Since bzlib is new to the kernel, I don't see a point in
keeping the uglies in the userspace interface for the kernel as well
and have already killed most of them.
However, one of the uglies, blockSize100k, is also part of the data
format as well, being one field in the header. So now I have to
decide whether to kill this wart or to keep it for compatibility.
The whole interface of the bzlib was modelled after the zlib
interface. blockSize100k is supposed to imitate the zlib compression
levels, the valid range is from 1 to 9 as well. The semantic is that
a block of 100k * blockSize100k is compressed at a time.
Now, the cost of the underlying BWT is O(n) in memory and O(n*ln(n))
in time. That given, I consider it odd to use a linear semantic of
blockSizeXXXX and would prefer an exponential one, as the zlib uses
here and there. Thus blockSizeBits would now give the blockSize as
1 << blockSizeBits, allowing to go well below 100k, resulting in lower
memory consumption for some and well above 900k, giving better
compression ratios.
Long intro, short question: Jay O Nay?
The change would make bzlib much more useful for jffs2, assuming it is
useful for jffs2 at all. But if any kernel bzlib users have to
interface with a userspace bzlib, things will break. That might be a
good reason to postpone the change for a while and rename the whole
thing when it gets done,,,, so my personal tendency is Nay.
Jörn
PS: Kept the surplus commata as a personal reminder that 2.5.72 still
has problems with my keyboard. Should check Andrews Must-Fix List and
add this one it not yet present.
--
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.
-- Edsger W. Dijkstra
next reply other threads:[~2003-06-20 18:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-20 18:59 Jörn Engel [this message]
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
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=20030620185915.GD28711@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=davem@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jmorris@intercode.com.au \
--cc=linux-kernel@vger.kernel.org \
/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®