Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 23 Nov 2018 12:41:02 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     Borislav Petkov <bp@alien8.de>
Cc:     "Moger, Babu" <Babu.Moger@amd.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
        "reinette.chatre@intel.com" <reinette.chatre@intel.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hpa@zytor.com" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>,
        "mchehab+samsung@kernel.org" <mchehab+samsung@kernel.org>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
        "pombredanne@nexb.com" <pombredanne@nexb.com>,
        "rafael@kernel.org" <rafael@kernel.org>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "qianyue.zj@alibaba-inc.com" <qianyue.zj@alibaba-inc.com>,
        "xiaochen.shen@intel.com" <xiaochen.shen@intel.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Singh, Brijesh" <brijesh.singh@amd.com>,
        "Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
        "luto@kernel.org" <luto@kernel.org>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "jannh@google.com" <jannh@google.com>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "rian@alum.mit.edu" <rian@alum.mit.edu>,
        "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v9 01/13] x86/resctrl: Rename and move rdt files to new
 directory
Message-ID: <20181123114102.GB130228@gmail.com>
References: <20181121202811.4492-1-babu.moger@amd.com>
 <20181121202811.4492-2-babu.moger@amd.com>
 <20181123072839.GA51597@gmail.com>
 <20181123082258.GA30697@zn.tnic>
 <20181123084117.GA130228@gmail.com>
 <20181123090011.GB30697@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181123090011.GB30697@zn.tnic>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* Borislav Petkov <bp@alien8.de> wrote:

> On Fri, Nov 23, 2018 at 09:41:17AM +0100, Ingo Molnar wrote:
> > Then at least make the directory name resource_control/, which is only 
> > marginally longer and a lot more readable.
> > 
> > We really don't have to fit directly names into the 8 character DOS limit 
> > anymore. ;-)
> 
> How about
> 
> resource_ctl
> 
> ?

The thing is, thinking about this as a 'CPU resource' is really a 
misnomer on the conceptual level, which is why it's bothering me: RDT is 
not really about 'CPU resources', because registers are CPU resources, 
ioports and iomem are CPU resources, APICs are CPU resources and PMU 
events are resources - none of which is part of RDT.

The key difference in RDT is that they are *shared* resources - caches 
really - where the ad-hoc cache sharing might be causing security and 
scalability problems so there's partitioning and throttling (bandwidth 
control) support in the hardware.

Is there any other resource handled than caches by RDT or by the AMD 
variant?

So how about "cache_control"? It's shorter and a lot closer to what the 
code actually does.

> resource_control/ is kinda long-ish and the other names we have there
> are nice and short, see below.
> 
> BTW, while we're talking renaming, I have a patch which renames the MCE
> pile and am planning to slap it in around -rc6 timeframe since we don't
> have a lot of RAS commits this time around, see also the end of this
> mail. It makes the naming there all nicely regular. :)

That's cool - these IMHO need to be done periodically to keep overall 
namespace complexity low enough. (As long as can be done without breaking 
any ABI that is.)

>  15 files changed, 14 insertions(+), 14 deletions(-)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/Makefile (52%)
>  rename arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/p5.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/threshold.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/winchip.c (100%)

Standardizing around 'MCE' sounds good to me!

Thanks,

	Ingo