linux-kernel - Re: [PATCH 01/14] x86/cpu: Move intel-family to arch-independent headers

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: <218ef97a68491e88d8012799385ee244544a157a.camel@intel.com>
Date:   Thu, 15 Jul 2021 16:47:16 +0000
From:   "Winiarska, Iwona" <iwona.winiarska@...el.com>
To:     "Williams, Dan J" <dan.j.williams@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>
CC:     "corbet@....net" <corbet@....net>,
        "jae.hyun.yoo@...ux.intel.com" <jae.hyun.yoo@...ux.intel.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        "andrew@...id.au" <andrew@...id.au>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "yazen.ghannam@....com" <yazen.ghannam@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "joel@....id.au" <joel@....id.au>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>
Subject: Re: [PATCH 01/14] x86/cpu: Move intel-family to arch-independent
 headers

On Wed, 2021-07-14 at 16:54 +0000, Williams, Dan J wrote:
> On Tue, 2021-07-13 at 00:04 +0200, Iwona Winiarska wrote:
> > Baseboard management controllers (BMC) often run Linux but are
> > usually
> > implemented with non-X86 processors. They can use PECI to access
> > package
> > config space (PCS) registers on the host CPU and since some
> > information,
> > e.g. figuring out the core count, can be obtained using different
> > registers on different CPU generations, they need to decode the
> > family
> > and model.
> > 
> > Move the data from arch/x86/include/asm/intel-family.h into a new
> > file
> > include/linux/x86/intel-family.h so that it can be used by other
> > architectures.
> 
> At least it would make the diffstat smaller to allow for rename
> detection when the old file is deleted in the same patch:
> 
>  MAINTAINERS                                                | 1 +
>  {arch/x86/include/asm => include/linux/x86}/intel-family.h | 6 +++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> ...one thing people have done in the past is include a conversion
> script in the changelog that produced the diff. That way if a
> maintainer wants to be sure to catch any new usage of the header at
> the old location they just run the script.

You mean like a simple s#asm/intel-family.h#linux/x86/intel-family.h#g
?
Operating on kernel tree? Or individual patches?

Is including "old" header in new code that big of a deal? I guess it
could break grepability (looking for users of the header, now that it
can be pulled from two different places).
It would be worse if someone decided to add new content to old header,
but this should be easier to catch during review.

> 
> I am not aware of x86 maintainer preference here. Either way you decide
> to go you can add:
> 
> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
> 

Thank you
-Iwona