linux-kernel - Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1260352852.19669.1253.camel@localhost>
Date:	Wed, 09 Dec 2009 12:00:52 +0200
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Phillip Lougher <phillip@...gher.demon.co.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-embedded@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, phillip.lougher@...il.com,
	tim.bird@...sony.com
Subject: Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code
 into a separate file

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@...gher.demon.co.uk> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/