[PATCH v2 1/1] nvme: use macro definitions for setting reservation values

Keith Busch kbusch at kernel.org
Tue Oct 25 16:09:21 PDT 2022


On Tue, Oct 25, 2022 at 05:19:14PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 03, 2022 at 01:16:36PM +0300, Max Gurtovoy wrote:
> >> I'd make this named nvme_pr_type
> >
> > Most of the enums of this header are not named.
> >
> > I don't understand what is the convention here.
> >
> > Usually, if it's not a new header file I'm trying to keep the file 
> > convention and this is what I did.
> >
> > If all agree on named, I'll send another version.
> 
> I think named is better, nvme has some weird unnamed enums that
> even combine totally unrelated fields which I always found confusing.

It's carry-over from the early days when structures had so few constants
that giving each field values their own enum looked a bit silly, and
enums were considered better than a bunch of #define's.

As far as naming them goes, if the only usage is its definition, then
what's the point? If there's a use for a named enum somewhere else, then
yah, that improves readability.



More information about the Linux-nvme mailing list