linux-kernel - Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Feb 2021 20:40:52 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     Ben Widawsky <ben.widawsky@...el.com>, linux-cxl@...r.kernel.org,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        "Chris Browy <cbrowy@...ry-design.com>, Christoph Hellwig
        <hch@...radead.org>, Dan Williams <dan.j.williams@...el.com>, David
        Hildenbrand <david@...hat.com>, David Rientjes" <rientjes@...gle.com>,
        "Jon Masters <jcm@...masters.org>, Rafael Wysocki
        <rafael.j.wysocki@...el.com>, Randy Dunlap" <rdunlap@...radead.org>,
        "John Groves (jgroves)" <jgroves@...ron.com>,
        "Kelley, Sean V" <sean.v.kelley@...el.com>,
        kernel test robot <lkp@...el.com>,
        Dan Williams <dan.j.willams@...el.com>
Subject: Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface

On Wed, Feb 10, 2021 at 10:47 AM Jonathan Cameron
<Jonathan.Cameron@...wei.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/

>
> 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.