Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper codeinto a separate file

From: Artem Bityutskiy
Date: Wed Dec 09 2009 - 05:01:45 EST


On Tue, 2009-12-08 at 22:20 +0000, Phillip Lougher wrote:
> Andrew Morton wrote:
> > On Mon, 07 Dec 2009 02:25:08 +0000
> > Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> >> +
> >> +int zlib_uncompress(struct squashfs_sb_info *msblk, void **buffer,
> >> + struct buffer_head **bh, int b, int offset, int length, int srclength,
> >> + int pages)
> >
> > This isn't a very good function name. zlib_uncompress() now becomes a
> > kernel-wide identifier, but it's part of squashfs, not part of zlib.
> >
> > Maybe that gets fixed in a later patch. If so, thwap me.
> >
>
> Yes, they get fixed up in [PATCH 3/9] Squashfs: add a decompressor framework.
> That patch makes the functions static, and instead exports them via a
> suitably named decompressor ops structure.
>
> +const struct squashfs_decompressor squashfs_zlib_comp_ops = {
> + .init = zlib_init,
> + .free = zlib_free,
> + .decompress = zlib_uncompress,
> + .id = ZLIB_COMPRESSION,
> + .name = "zlib",
> + .supported = 1
> +};
>
> I split the patches up to make them easier to review. The first two patches
> move the zlib code out to a separate file (ready for adding the framework).
> The third patch adds the framework. At the time of the second patch, however,
> to not break compilation, the functions have to be global. In hindsight
> I should have made named the functions squashfs_xxx, and removed the squashfs_
> when they were made static in the third patch.

Did you consider using cryptoapi? UBIFS uses zlib/lzo in cryptoapi - it
is a very clean way.

--
Best Regards,
Artem Bityutskiy (ÐÑÑÑÐ ÐÐÑÑÑÐÐÐ)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/