[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BD7FB879CC136E419544C8E2AE7B9C3020C7FA@IN01WEMBXA.internal.synopsys.com>
Date: Thu, 7 Jun 2018 06:55:42 +0000
From: Ladvine D Almeida <Ladvine.DAlmeida@...opsys.com>
To: Jens Axboe <axboe@...nel.dk>,
Ladvine D Almeida <Ladvine.DAlmeida@...opsys.com>,
Christoph Hellwig <hch@...radead.org>
CC: Hannes Reinecke <hare@...e.com>,
"ming.lei@...hat.com" <ming.lei@...hat.com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Manjunath M Bettegowda <Manjunath.MB@...opsys.com>,
Prabu Thangamuthu <Prabu.T@...opsys.com>,
Tejas Joglekar <Tejas.Joglekar@...opsys.com>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Johannes Thumshirn <jthumshirn@...e.de>,
"Milan Broz" <gmazyland@...il.com>,
Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...hat.com>,
device-mapper development <dm-devel@...hat.com>,
"Eric Biggers" <ebiggers3@...il.com>,
Theodore Ts'o <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>
Subject: Re: [PATCH] block: Add block level changes for inline encryption
On Thursday 07 June 2018 02:53 AM, Jens Axboe wrote:
> On 6/6/18 1:35 AM, Ladvine D Almeida wrote:
>> On Friday 01 June 2018 09:13 AM, Christoph Hellwig wrote:
>>> On Mon, May 28, 2018 at 02:43:09PM +0100, Ladvine D Almeida wrote:
>>>> This patch introduces new variable under bio structure to
>>>> facilitate inline encryption. This variable is used to
>>>> associate I/O requests to crypto information.
>>> This seems to be missing a whole lot of context. Where is the whole
>>> series showing what you are trying to do?
>>>
>> Christoph,
>>
>> The patches are generated in the below > manner, with a thought of
>> sending separately to the MAINTAINERS responsible for each.
> What both Christoph and I have said is that it's _impossible_ to review
> changes when you don't know what is being built on top of it. The block
> change, by itself, is utterly useless. The use case needs to be seen.
> But apart from that, my comments on why it's doing it completely
> backwards still apply, and I've outlined how you need to fix it. The
> patch, in its current form, isn't going anywhere.
>
Jens,
Since there are implementation level concerns on both device mapper layer and block layer, I will investigate
more and work on those lines. I can send the full patch series to the relevant maintainers after addressing the
issues.
Regards,
Ladvine
Powered by blists - more mailing lists