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@xxxxxxxxx/ 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.
