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 09:41:17 +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: <20181123084117.GA130228@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181123082258.GA30697@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 08:28:39AM +0100, Ingo Molnar wrote:
> > Ugh, violent NAK on this unreadable directory naming: 'resctrl' is an 
> > ugly double/triple abbreviation that nobody recognizes for what it is to 
> > begin with, and even the long form 'resource control' is an overly 
> > generic naming - *everything* the kernel does is in essence 'resource 
> > control' ...
> 
> Well, the fs this thing uses is called "resctrl".
> 
> Documentation/x86/resctrl_ui.txt:1075:the resctrl will still mount but cannot create CTRL_MON directories.
> Documentation/x86/resctrl_ui.txt:1082:# mount -t resctrl resctrl /sys/fs/resctrl
> Documentation/x86/resctrl_ui.txt:1083:# cd /sys/fs/resctrl
> 
> Are you saying that the fs should be renamed now too?

Sigh, probably not. I only noticed this naming snafu with the renaming 
commit. The high level name was always RDT-ish - which while an acronym 
is at least is a familiar high level name now with no obvious generic 
namespace collision, while 'resctrl' less so.

> How are those *abbreviations* better? "hw_bw" is especially cryptic and 
> the others are no better.

Those were suggestions - but I'd be fine with 'resource_control':

> "resctrl" to mean "resource control" is much better IMO.

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. ;-)

> [...] And it is different from the "other" resource controlling the 
> kernel does because it is under arch/x86/kernel/cpu/ which tells you it 
> is a *CPU* resource control.

Yeah, so this is not obvious from the filesystem name, nor does it excuse 
the pointless abbreviation.

High level names matter.

Also, the Kconfig space, when it gets extended with the AMD bits, should 
probably follow the same nomenclature: CONFIG_X86_CPU_RESOURCE_CONTROL=y 
or such.

	Ingo