[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56B2CA96.4010104@intel.com>
Date: Thu, 4 Feb 2016 11:50:46 +0800
From: "Li, Weigang" <weigang.li@...el.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: 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>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression
support
On 2/4/2016 11:29 AM, Herbert Xu wrote:
> On Thu, Feb 04, 2016 at 11:28:50AM +0800, Herbert Xu wrote:
>> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>>>
>>> Please can you advise how to get the acomp patch accepted?
>>
>> Can you do a posting of these patches without scomp so we can
>> evaluate the effects?
>
> Of course you can keep the driver-side scomp interface as otherwise
> the implementation would be unnecessarily complicated.
>
> Cheers,
>
Seems I need go back to my first acomp patch.. Assuming we shall still
keep the comp i/f, and the linearisation of sg-list in acomp to fit the
"comp" API? What do you mean by the driver-side scomp? Thanks!
Powered by blists - more mailing lists