lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181123084117.GA130228@gmail.com>
Date:   Fri, 23 Nov 2018 09:41:17 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Moger, Babu" <Babu.Moger@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "reinette.chatre@...el.com" <reinette.chatre@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "pombredanne@...b.com" <pombredanne@...b.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "qianyue.zj@...baba-inc.com" <qianyue.zj@...baba-inc.com>,
        "xiaochen.shen@...el.com" <xiaochen.shen@...el.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Singh, Brijesh" <brijesh.singh@....com>,
        "Hurwitz, Sherry" <sherry.hurwitz@....com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "luto@...nel.org" <luto@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "rian@...m.mit.edu" <rian@...m.mit.edu>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v9 01/13] x86/resctrl: Rename and move rdt files to new
 directory


* Borislav Petkov <bp@...en8.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ