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;
Date:   Thu, 11 Feb 2021 10:06:46 +0000
From:   Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To:     Dan Williams <dan.j.williams@intel.com>
CC:     Ben Widawsky <ben.widawsky@intel.com>, <linux-cxl@vger.kernel.org>,
        "Linux ACPI" <linux-acpi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-nvdimm <linux-nvdimm@lists.01.org>,
        Linux PCI <linux-pci@vger.kernel.org>,
        Bjorn Helgaas <helgaas@kernel.org>,
        "Chris Browy <cbrowy@avery-design.com>, Christoph Hellwig
        <hch@infradead.org>, Dan Williams <dan.j.williams@intel.com>, David
        Hildenbrand <david@redhat.com>, David Rientjes" <rientjes@google.com>,
        "Jon Masters <jcm@jonmasters.org>, Rafael Wysocki
        <rafael.j.wysocki@intel.com>, Randy Dunlap" <rdunlap@infradead.org>,
        "John Groves (jgroves)" <jgroves@micron.com>,
        "Kelley, Sean V" <sean.v.kelley@intel.com>,
        "kernel test robot" <lkp@intel.com>,
        Dan Williams <dan.j.willams@intel.com>
Subject: Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface
Message-ID: <20210211100646.00007dcc@Huawei.com>
In-Reply-To: <CAPcyv4hRUB3jxdCV06y0kYMbKbGroEW6F9yOQ4KB_z6YgWBZ4Q@mail.gmail.com>
References: <20210210000259.635748-1-ben.widawsky@intel.com>
        <20210210000259.635748-5-ben.widawsky@intel.com>
        <20210210184540.00007536@Huawei.com>
        <CAPcyv4hRUB3jxdCV06y0kYMbKbGroEW6F9yOQ4KB_z6YgWBZ4Q@mail.gmail.com>
Organization: Huawei Technologies Research and Development (UK) Ltd.
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 10 Feb 2021 20:40:52 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> On Wed, Feb 10, 2021 at 10:47 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> [..]
> > > +#define CXL_CMDS                                                          \
> > > +     ___C(INVALID, "Invalid Command"),                                 \
> > > +     ___C(IDENTIFY, "Identify Command"),                               \
> > > +     ___C(MAX, "Last command")
> > > +
> > > +#define ___C(a, b) CXL_MEM_COMMAND_ID_##a
> > > +enum { CXL_CMDS };
> > > +
> > > +#undef ___C
> > > +#define ___C(a, b) { b }
> > > +static const struct {
> > > +     const char *name;
> > > +} cxl_command_names[] = { CXL_CMDS };
> > > +#undef ___C  
> >
> > Unless there are going to be a lot of these, I'd just write them out long hand
> > as much more readable than the macro magic.  
> 
> This macro magic isn't new to Linux it was introduced with ftrace:
> 
> See "cpp tricks and treats": https://lwn.net/Articles/383362/

Yeah. I've dealt with that one a few times. It's very cleaver and compact
but a PITA to debug build errors related to it.

> 
> >
> > enum {
> >         CXL_MEM_COMMAND_ID_INVALID,
> >         CXL_MEM_COMMAND_ID_IDENTIFY,
> >         CXL_MEM_COMMAND_ID_MAX
> > };
> >
> > static const struct {
> >         const char *name;
> > } cxl_command_names[] = {
> >         [CXL_MEM_COMMAND_ID_INVALID] = { "Invalid Command" },
> >         [CXL_MEM_COMMAND_ID_IDENTIFY] = { "Identify Comamnd" },
> >         /* I hope you never need the Last command to exist in here as that sounds like a bug */
> > };
> >
> > That's assuming I actually figured the macro fun out correctly.
> > To my mind it's worth doing this stuff for 'lots' no so much for 3.  
> 
> The list will continue to expand, and it eliminates the "did you
> remember to update cxl_command_names" review burden permanently.

How about a compromise.  Add a comment giving how the first entry expands to
avoid people (me at least :) having to think their way through it every time?

Jonathan