linux-kernel - Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 5 Feb 2016 01:19:29 +0900
From:	Joonsoo Kim <js1304@...il.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"Li, Weigang" <weigang.li@...el.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	"David S. Miller" <davem@...emloft.net>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Minchan Kim <minchan@...nel.org>,
	Dan Streetman <ddstreet@...e.org>,
	linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression support

2016-02-04 23:53 GMT+09:00 Herbert Xu <herbert@...dor.apana.org.au>:
> On Thu, Feb 04, 2016 at 04:17:41PM +0900, Joonsoo Kim wrote:
>>
>> Do you think not to merge scomp? Please let me know your overall
>> plan about this.?
>
> I'm fine with a driver-side scomp interface.  But I'd rather
> avoid having yet another user-side compression interface in the
> form of scomp if we can avoid it.

I mentioned that there are usecases that scomp is needed for performance,
it means that we can't avoid it. Or do you think this usecase differently?
I understand it's rather pain that we have two interfaces but scomp interface
is just wrapping layer to handle various S/W compression algorithms and
implementation is not that complex. I guess it doesn't cause much
maintenance cost.

Thanks.