[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6b50671d-883f-561a-bf7d-5ae01c2cc312@intel.com>
Date: Mon, 14 Feb 2022 11:20:20 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Ira Weiny <ira.weiny@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Dan Williams <dan.j.williams@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS
On 2/8/22 21:34, Ira Weiny wrote:
>>> 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.
It's a bit more clear. I wish it was more clear about the problem. I
think it would be well-served to add some specifics and clarify the
*problem*. Maybe something like:
== Problem ==
PKS support is provided by core x86 architecture code. Its consumers,
however, may be far-flung device drivers like NVDIMM support. The PKS
core architecture code is dead weight without a consumer.
--- maybe add one example ---
== Solution ==
Avoid even compiling in the core PKS code if there are no consumers.
== Details ==
Powered by blists - more mailing lists