lkml.org 
[lkml]   [2022]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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,
}

\
 
 \ /
  Last update: 2022-02-04 18:13    [W:0.244 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site