[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705290815y32758055te52cb8657f34acc@mail.gmail.com>
Date: Tue, 29 May 2007 20:45:41 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Daniel Hazelton" <dhazelton@...er.net>
Cc: "Michael-Luke Jones" <mlj28@....ac.uk>,
lkml <linux-kernel@...r.kernel.org>, dwmw2@...radead.org,
madler@...mni.caltech.edu, jloup@...p.org
Subject: Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)
[ Trimmed Cc list; added original zlib authors. ]
> On Tuesday 29 May 2007 09:33:51 Michael-Luke Jones wrote:
> > On 29 May 2007, at 12:27, Satyam Sharma wrote:
> > > Right, actually, zlib could be switched over to [using a common
> > > directory].
> > > Because zlib_deflate/ and zlib_inflate/ too share a private header
> > > zutil.h which has unfortunately been stuck into include/linux/ with
> > > a big
> > > /* WARNING: this file should *not* be used by applications. */
> > > comment ...
> >
> > Well, unfortunately zutil.h is currently being used in-kernel by fs/
> > jffs2/compr_zlib.c despite the "WARNING: this file should *not* be
> > used by applications" notice.
Hmmm, either jffs2 thinks the zlib interfaces exposed through
include/linux/zlib.h are insufficient, or it isn't using zlib properly
(or at least the way it was supposed to be used :-)
Looking at fs/jffs2/compr_zlib.c, however, it just seems to be
an optimization -- skipping some checksum calculation if some
flag (PRESET_DICT) is absent from the input stream about to
be decompressed ...
This /looks/ like an optimization that might make sense for other
users of zlib too, in which case that entire check and
skip-the-checksum thing could actually be put into zlib proper. (?)
> > So moving this header to a truly private location isn't possible
> > right now, unfortunately,
> >
> > Michael-Luke Jones
> > [added David Whitehouse to cc]
On 5/29/07, Daniel Hazelton <dhazelton@...er.net> wrote:
> I've looked at that code and it seems to need that file for one constant.
> Perhaps it'd be better for jffs2/compr_zlib.c to define that constant itself
> (or use it as a "Magic Number") rather than include the zlib private header.
> Another possibility would be to move that constant out of zutil.h and into
> zconf.h or zlih.b - doing any of those would allow the zlib private header to
> be moved such that zlib could be changed to use a common directory *and* have
> said private header in that directory.
Moving PRESET_DICT to zlib.h robs lib/zlib_deflate/deflate.c from
being able to resolve that macro. FWIW, a dirty hack could be to
simply duplicate it in zlib.h. But then, implementation and interface
are decoupled for good reasons ...
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists