[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


  • To: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 25 Oct 2023 18:01:15 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CP3WSlakdVikstFUZAG7JpmFfzK2ajP45pzYhA/Ds2A=; b=LXXeMpYgEm481efv7FwtChXo0+tl0n5fSMTB3JWskAH4rnImvcnqTO9SYxPR0/hu9r97FaaZN8CsBikwPyHbIujOsodyA05ItEEEgiEi7reFqwBRFjSPfrCohF8ubxUbiQl0Gw10o0N62yZ9giqKQSdky+9OycLYaeIKp/SzV/Cuhyljb1FPHZC+58wa55FtXgtbnhCSozow7fPsSoPvvsUHQVjd43m7W4ckf9u2FNHVevucQKv6ko0vEK/iVeaKHuLepPkfA6T9zwybu0jvJjzinKxNrUwH8RmCLZWsBTKzqXQFCwKILHb4TynIEk1Fo9TnmjgDV8bmrJo0Xe+VEg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RAqpLIKk/r7DCWFlYQVeR3rZNHkkG38hEA8JA1R+MaKf5YHzY5aH5DqJm2e2oe0BLdH/ng2yqPUCuXJab73WsJBpPNEmli+KmHQIlOX+xCRoC+G9h35g0RWyxlsjxGGyyy602r438h231JOTHxDV0Nk4JzJFi3CmAc+TIqeEKR9WGEE/WsVPNtb0fVdvob1AeerLv56kzRgXtkO9WynGJfEUn7cTYKhp+AlRkZiPVirErsR0EvFbzmSZzZo2Y4dDNeUVMV1HaXq2AeqXxCiXBqDgYWJhm9Nmm5+Tauf9q9yLmmG1vLRA0QDq+nQjBwa67gda9gopEpUgoP6AUsZlbg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <stefano.stabellini@xxxxxxx>, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 25 Oct 2023 16:01:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Jan



 


Rackspace

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