Re: [PATCH v11 05/12] x86/mm: add INVLPGB support code

[Dave Hansen <dave.hansen@intel.com>]

On 2/19/25 09:42, Rik van Riel wrote:
> On Wed, 2025-02-19 at 13:04 +0100, Borislav Petkov wrote:
>> On Thu, Feb 13, 2025 at 11:13:56AM -0500, Rik van Riel wrote:
>>>
>>> index 000000000000..a1d5dedd5217
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/invlpgb.h
>>
>> I remember asking you to add all that gunk to
>> arch/x86/include/asm/tlb.h.
>> Please do so.
> 
> Dave just asked me to split out more things into
> their own files.
> 
> I'm happy to do whatever the maintainers want,
> but when you both want the opposite from each
> other, I won't be able to make you both happy.
> 
> What should I be doing here?

I think you're referring to this:

> https://lore.kernel.org/all/b067a9fc-ff5f-4baa-a1ff-3fa749ae4d44@intel.com/

I don't have a strong preference about creating an invlpgb.h header. As
long as the header is still relatively small the #ifdef pile is
readable, it's fine to stick in an existing header.

The thing I raised about the 09/12 patch was a large #ifdef in a .c
file. We have a general rule to avoid #ifdefs in .c files. Specifically,
I find that having large #ifdef's regions in a .c file means that you
literally can't see both sides of the #ifdef at once or easily
understand which code belongs to the #ifdef. The result is invariably
weird compile issues that pop up.

But, either way, #ifdefs are a sign of weakness. Less so in a header and
more so in a .c file.