Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Oak6ppXbc/Do1BcjmbaM4QK62RB2d7OPfb//1eyyECHXeHoQC5s3zNN/vmlTY2NOLlS1jif4lW
 fnrwmdOaCrfOZ4rZ+7h/WRxPF5qEICQZ9/wyo4XsIOBcK2lMdh+6nM4CS8jGJ/R2TDL4ABpmIJ
 JcrabA4ri9Qa3Ws8g9e5PMc2pJ0hGW+SEqsJvWv/uHui39R0XVODOZn3ks4eEnCKcS8bhQ1GkZ
 cnSJCRAw4Qg0TEXL8gqZWc5eigh80zLMMN3B8gxgrgDyNBlMA/Cdj+umzBV2eYa7TfffuIwiSD
 4GE=
From:   Niklas Cassel <Niklas.Cassel@wdc.com>
To:     Christoph Hellwig <hch@lst.de>
CC:     Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
        Sagi Grimberg <sagi@grimberg.me>,
        Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed fields
 in initializers
Thread-Topic: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed fields
 in initializers
Thread-Index: AQHWRatsK9pqpN/HlEmT0NtnEgioaqjoAiyAgAADqACAAAE8gIAAAa2A
Date:   Wed, 24 Jun 2020 17:08:12 +0000
Message-ID: <20200624170811.GA396203@localhost.localdomain>
References: <20200618200235.1104587-1-niklas.cassel@wdc.com>
 <20200624164441.GA24816@lst.de>
 <20200624165746.GA394355@localhost.localdomain>
 <20200624170211.GA25230@lst.de>
In-Reply-To: <20200624170211.GA25230@lst.de>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C2A3B0F50ADC18448F8995778D7268AE@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b4d48fc2-081f-4b4e-87d8-08d818612da4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 17:08:12.7897
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vExUhjQGYgqJcisu60sEuBgkmjNzGnSnH+P2IpClEs9Qbwy7WNbD4Y9QemQfprnCZ5e4Coqplg1cgVWSszLB2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB3976
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jun 24, 2020 at 07:02:11PM +0200, Christoph Hellwig wrote:
> 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.
> >=20
> > 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.
> >=20
> > IMHO, using an initializer is more clear.
> >=20
> > 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).
> >=20
> > What do you think about me unifying this later on?
>=20
> I like the initializers a lot.  But as I said I'd rather wait a
> bit for now.

Just to be clear:
Even with these patches, about half of the nvme functions are using
memset rather than initializers.

But sure, I'll wait a couple of releases, and then rebase this,
and additionally convert the "struct nvme_command c" memset users
to use initializers.


Kind regards,
Niklas=