Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS

[Ira Weiny]

On Fri, Feb 04, 2022 at 11:08:51AM -0800, 'Ira Weiny' wrote:
> On Fri, Jan 28, 2022 at 03:51:56PM -0800, Dave Hansen wrote:
> > On 1/28/22 15:10, Ira Weiny wrote:
> > > This issue is that because PKS users are in kernel only and are not part of the
> > > architecture specific code there needs to be 2 mechanisms within the Kconfig
> > > structure.  One to communicate an architectures support PKS such that the user
> > > who needs it can depend on that config as well as a second to allow that user
> > > to communicate back to the architecture to enable PKS.
> > 
> > I *think* the point here is to ensure that PKS isn't compiled in unless
> > it is supported *AND* needed.
> 
> Yes.
> 
> > You have to have architecture support
> > (ARCH_HAS_SUPERVISOR_PKEYS) to permit features that depend on PKS to be
> > enabled.  Then, once one ore more of *THOSE* is enabled,
> > ARCH_ENABLE_SUPERVISOR_PKEYS comes into play and actually compiles the
> > feature in.
> > 
> > In other words, there are two things that must happen before the code
> > gets compiled in:
> > 
> > 1. Arch support
> > 2. One or more features to use the arch support
> 
> Yes.  I really think we are both say the same thing with different words.

Is the following more clear?

<commit>

PKS is only useful to kernel consumers and is only available on some
architectures.  If no kernel consumers are configured or PKS support is
not available the PKS code can be eliminated from the compile.

Define a Kconfig structure which allows kernel consumers to detect
architecture support (ARCH_HAS_SUPERVISOR_PKEYS) and, if available,
indicate that PKS should be compiled in (ARCH_ENABLE_SUPERVISOR_PKEYS).

In this patch ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first
kernel consumer sets it.

</commit>

Thanks,
Ira