linux-kernel - Re: [PATCH 2/8] x86/platform/uv: Return UV Hubless System Type

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: <b342b250-a427-60cf-6189-3eb3225e5c91@hpe.com>
Date:   Tue, 3 Sep 2019 11:49:53 -0700
From:   Mike Travis <mike.travis@....com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Russ Anderson <russ.anderson@....com>,
        Hedi Berriche <hedi.berriche@....com>,
        Steve Wahl <steve.wahl@....com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 2/8] x86/platform/uv: Return UV Hubless System Type

On 9/3/2019 8:41 AM, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 07:12:28AM -0700, Mike Travis wrote:
>>>> +#define is_uv_hubless _is_uv_hubless
>>>
>>> Why the weird macro indirection?
>>>
>>>> -static inline int is_uv_hubless(void)	{ return 0; }
>>>> +static inline int _is_uv_hubless(int uv) { return 0; }
>>>> +#define is_uv_hubless _is_uv_hubless
>>>
>>> And here again.
>>>
>>
>> Sorry, I should have explained this better.  The problem arises because
>> we have a number of UV specific kernel modules that support multiple
>> distributions.  And with back porting to earlier distros we cannot
>> rely on the KERNEL_VERSION macro to define whether the source is being
>> built for an earlier kernel.  So this allows an ifdef on the function
>> name to discover if the kernel is before or after these changes.
> 
> And none of these matter for upstream.  We'd rather not make the code
> more convouluted than required.  If you actually really cared about these
> modules you would simply submit them upstream.
> 

That is always being considered for everything we include into the 
community kernel source.  The problem is a couple of the kernel modules 
(hwperf being the prime example) is much more tied to hardware and 
BIOS/FW updates so has to be updated much more often than the current 
submittal/acceptance process allows.  We do opensource these modules but 
they are built from single source directories and have to be released as 
a module into a package that can be installed on different distros. 
There is not a source version for each kernel version.

I have seen this method (declare the function with a leading underscore 
and a #define for the function reference) which is why I'm assuming it's 
a standard kernel practice?  (I'll find some examples if necessary?)