On 25.10.2023 23:12, Stefano Stabellini wrote: > On Wed, 25 Oct 2023, Julien Grall wrote: >> On 25/10/2023 17:01, Jan Beulich wrote: >>> On 25.10.2023 17:58, Julien Grall wrote: >>>> On 25/10/2023 09:18, Jan Beulich wrote: >>>>> On 24.10.2023 21:59, Stefano Stabellini wrote: >>>>>> If I understood correctly I am fine with that. To make sure we are all >>>>>> on the same page, can you provide a couple of samples? >>>>> >>>>> Taking the earlier example, instead of DRIVERS_PASSTHROUGH_VTD_DMAR_H it >>>>> would then be VTD_DMAR_H. arch/x86/pv/mm.h would use PV_MM_H, but then >>>>> you can already see that a hypothetical arch/x86/mm.h would use >>>>> X86_MM_H, >>>>> thus colliding with what your proposal would also yield for >>>>> arch/x86/include/asm/mm.h. So maybe private header guards should come >>>>> with e.g. a trailing underscore? Or double underscores as component >>>>> separators, where .../include/... use only single underscores? Or >>>>> headers in arch/*/include/asm/ use ASM_<name>_H (i.e. not making the >>>>> architecture explicit in the guard name, on the grounds that headers >>>>> from multiple architectures shouldn't be included at the same time)? >>>> Thanks for providing some details. The proposal for private headers >>>> make sense. For arch/.../include/asm/ headers, I would strongly prefer >>>> if we use prefix them with ASM_*. >>>> >>>> As a side note, I am guessing for asm-generic, we would want to use >>>> ASM_GENERIC_* for the guard prefix. Is that correct? >>> >>> That was an assumption I was working from, yes. Could also be just >>> GENERIC_ afaic. >> >> Thanks for the confirmation. I am fine with either GENERIC_ or ASM_GENERIC_. > > OK. So in summary: > - arch/.../include/asm/ headers would use ASM_<filename>_H > - private headers would use <dir>_<filename>_H > - asm-generic headers would use ASM_GENERIC_<filename>_H > > If that's agreed, we can move forward with the patch following this > scheme.
FTAOD - just as long as <dir> is clarified to mean only the leaf-most directory component (assuming we're still talking about the most recently proposed scheme and we deem the risk of collisions low enough there). Jan
