Messages in this thread | | | From | Dan Williams <> | Date | Fri, 4 Feb 2022 09:12:11 -0800 | Subject | Re: [PATCH V8 36/44] memremap_pages: Reserve a PKS PKey for eventual use by PMEM |
| |
On Tue, Feb 1, 2022 at 10:35 AM Edgecombe, Rick P <rick.p.edgecombe@intel.com> wrote: > > On Thu, 2022-01-27 at 09:54 -0800, ira.weiny@intel.com wrote: > > enum pks_pkey_consumers { > > - PKS_KEY_DEFAULT = 0, /* Must be 0 for default PTE > > values */ > > - PKS_KEY_TEST = 1, > > - PKS_KEY_NR_CONSUMERS = 2, > > + PKS_KEY_DEFAULT = 0, /* Must be 0 for default > > PTE values */ > > + PKS_KEY_TEST = 1, > > + PKS_KEY_PGMAP_PROTECTION = 2, > > + PKS_KEY_NR_CONSUMERS = 3, > > }; > > The c spec says that any enum member that doesn't have an "=" will be > one more than the previous member. As a consequence you can leave the > "=" off PKS_KEY_NR_CONSUMERS and it will get auto adjusted when you add > more like this. > > I know we've gone around and around on this, but why also specify the > value for each key? They should auto increment and the first one is > guaranteed to be zero. > > Otherwise this doesn't use any of the features of "enum", it's just a > verbose series of const int's.
Going further, this can also build in support for dynamically (at build time) freeing keys based on config, something like:
enum { #if IS_ENABLED(CONFIG_PKS_TEST) PKS_KEY_TEST, #endif #if IS_ENABLED(CONFIG_DEVMAP_PROTECTION) PKS_KEY_PGMAP_PROTECTION, #endif PKS_KEY_NR_CONSUMERS, }
| |