[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200624170211.GA25230@lst.de>
Date: Wed, 24 Jun 2020 19:02:11 +0200
From: Christoph Hellwig <hch@....de>
To: Niklas Cassel <Niklas.Cassel@....com>
Cc: Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
Jens Axboe <axboe@...com>, Sagi Grimberg <sagi@...mberg.me>,
Chaitanya Kulkarni <Chaitanya.Kulkarni@....com>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed
fields in initializers
On Wed, Jun 24, 2020 at 04:57:48PM +0000, Niklas Cassel wrote:
> On Wed, Jun 24, 2020 at 06:44:41PM +0200, Christoph Hellwig wrote:
> > This looks good to me, but I'd rather wait a few releases to
> > avoid too mush backporting pain.
>
> Chaitanya made me realize that about half of the nvme functions
> are using "struct nvme_command c" on the stack, and then memsets
> it, and half of the nvme functions are using an initializer.
>
> IMHO, using an initializer is more clear.
>
> memset has to be used if the function needs to reset an
> existing struct, but in none of the functions that I've seen,
> are we given an existing nvme_command that we need to reset.
> All the functions that I've seen declares a new nvme_command
> on the stack (so an initializer makes more sense).
>
> What do you think about me unifying this later on?
I like the initializers a lot. But as I said I'd rather wait a
bit for now.
Powered by blists - more mailing lists