[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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?)

 \ /
  Last update: 2019-09-03 20:50    [W:0.044 / U:64.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site