[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2 00/10] address violations of MISRA C:2012 Directive 4.10





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_.

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.