Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp742143ybt; Wed, 24 Jun 2020 10:05:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIuak0DKj7x3NZ6C913curQHuj+PFjgYq6eI1xAvZsrMiFPMBgq5HLdgKPhPAU87xDOYah X-Received: by 2002:a17:906:2e84:: with SMTP id o4mr6569862eji.65.1593018315412; Wed, 24 Jun 2020 10:05:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593018315; cv=none; d=google.com; s=arc-20160816; b=Jf8VgNuupMXAPToBIGLxEe+xrwIW0Rc+bV/nMlo292Wb300wbjW2jRPCdQWdCsxp0a 9mRcawG8IXE/ny9pw9p0RSEmK1p/v+mnOnvKk+nhusGlY/PY1c3Xj/eJqESg4KxU9cIq wRQ1Gev+lSqMjxQi0D1vkNq3iRb7omVuVbCOeonA4L2QYUFHyyMHb4ro+xZgCbjLWard 5piDfrxlMGz0CHgqGqA8ckhgNK7KlmTluSsJzQki22gA12VBNDTVM4HA8YVIV+8keBmP gLCKzixxSdjzEg9EAe12V9vmar1ONB3rKRyy5bu67j9FsH7yXj1eySYhB1KC300YNea7 iLMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jGAklPoYlrLDWokTXMmEgIiZDHcDbnotedNhO4ZnU3M=; b=HkPZQACn3hNAzEzQg8anwfUx71dGVVGLMRzIFhvS8rF+0gzI3bn8eK7HB9WJDQR1Na OZajSsq0O/IXu7mCG9i3V0xmjsg/NJsjfCCz5COMCznzgRm/lIzkonsOuW/ZvmK07VVg RmVaHOcK2vXRPpgxW0MTwR2sxyQxciX4Eq8z/Fnrc6/WlBZdzTCGtgGDVCszPHe8dO3A czp80mfGR/cEyrg2RVdU4X/K3YUuEGAlPLTEeCQsbNL626e0by+eQ0dLOVsacngUkBfY vZPu/CQtWy2WGCD2MNryt9hcIutekIjQ3CbfFBzFOsfvgLB8WYTirDSlZiN6x0OpWmYy Vfyg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp9si17060526ejc.698.2020.06.24.10.04.51; Wed, 24 Jun 2020 10:05:15 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405348AbgFXRCS (ORCPT + 99 others); Wed, 24 Jun 2020 13:02:18 -0400 Received: from verein.lst.de ([213.95.11.211]:45238 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404959AbgFXRCR (ORCPT ); Wed, 24 Jun 2020 13:02:17 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 65A5768BFE; Wed, 24 Jun 2020 19:02:11 +0200 (CEST) Date: Wed, 24 Jun 2020 19:02:11 +0200 From: Christoph Hellwig To: Niklas Cassel Cc: Christoph Hellwig , Keith Busch , Jens Axboe , Sagi Grimberg , Chaitanya Kulkarni , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed fields in initializers Message-ID: <20200624170211.GA25230@lst.de> References: <20200618200235.1104587-1-niklas.cassel@wdc.com> <20200624164441.GA24816@lst.de> <20200624165746.GA394355@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200624165746.GA394355@localhost.localdomain> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.