[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8/A8yYcU0QXVRGG@zn.tnic>
Date: Tue, 24 Jan 2023 12:28:51 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: "Moger, Babu" <babu.moger@....com>,
"corbet@....net" <corbet@....net>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"paulmck@...nel.org" <paulmck@...nel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"quic_neeraju@...cinc.com" <quic_neeraju@...cinc.com>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"damien.lemoal@...nsource.wdc.com" <damien.lemoal@...nsource.wdc.com>,
"songmuchun@...edance.com" <songmuchun@...edance.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"jpoimboe@...nel.org" <jpoimboe@...nel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>,
"pawan.kumar.gupta@...ux.intel.com"
<pawan.kumar.gupta@...ux.intel.com>,
"jmattson@...gle.com" <jmattson@...gle.com>,
"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
"sandipan.das@....com" <sandipan.das@....com>,
"james.morse@....com" <james.morse@....com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bagasdotme@...il.com" <bagasdotme@...il.com>,
"Eranian, Stephane" <eranian@...gle.com>,
"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"Hunter, Adrian" <adrian.hunter@...el.com>,
"quic_jiles@...cinc.com" <quic_jiles@...cinc.com>,
"peternewman@...gle.com" <peternewman@...gle.com>
Subject: Re: [PATCH v11 04/13] x86/cpufeatures: Add Bandwidth Monitoring
Event Configuration feature flag
On Mon, Jan 09, 2023 at 09:50:20PM +0000, Luck, Tony wrote:
> But that allows for the flimsiest of reasons to used to justify making a
> flag visible.
How's that for starters?
c: The naming override can be "", which means it will not appear in /proc/cpuinfo.
----------------------------------------------------------------------------------
The feature shall be omitted from /proc/cpuinfo if there is no valid use case
for userspace to query this flag and cannot rely on other means for detecting
feature support. For example, toolchains do use CPUID directly instead of
relying on the kernel providing that info.
If unsure, that flag can always be omitted initially and, once a valid use case
presents itself, be shown later. Not the other way around.
Another example is X86_FEATURE_ALWAYS, defined in cpufeatures.h. That flag is an
internal kernel feature used in the alternative runtime patching functionality.
So, its name is overridden with "". Its flag will not appear in /proc/cpuinfo
because it absolutely does not make any sense to appear there.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists