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

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


  • To: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 12 Sep 2023 12:00:05 +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=Dfq6+z7cHpZGHCVA9Ojrv0NxQHhu1cDK4S/z3KgFqFI=; b=aA7aBH1KIOlr2vX33E7+G5kZo/97Z9kNpc1hnX3s0QyrATvJSj92Uvresucg3tKxFi35/xUgroYvjni9je+eg1meQJ09py6RFM+NOCDj0tBPvIjDLHvvQa0HbHaL9lpQzKwZ1kKHFPuTefINvDip6UgzSKlSiwZu2tD2qDNPz/IatYdQCsEHPe2m9ky+QyYZbetwgr5iQU29MwT0DzeESVAPXk6ym3U9T7za0WmWsceN3/Eq4UbhEozooAtxw7VP94ZfyaV1YQY4Li98kykEll5alaBQkrnBKoXPaAQhWppkXKbwOpZef9jHnmZ0/+ssVBpVrC7JZMOUe7n7r60o8g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xy0K/KOyn8aam4xs9AQW0X8Oo6v8wVRZBxgZmzS5nkgM1tdbqSWC3Gkz/73wH2z4lvoErkBSccPLHXH0bkkxcR1zwN+w57zagAir+RCCOeBurTUNmPY5KRfc0YhHX23nvwKYmFPLcJGLrtt1nPSbSsOmomlrbjV2cQKxLZZOI05BnEfu2VFamvK8Wy0qwXn3LT2LXEz5JttWVXCuIt5yqGHqOMPmepeMaoOwdfKan8r8a6daWgQaG3nGZkC/PuhzOpbvol7FrV6a26YZv7o9Pp+/a09I0BPym3F+1rQM/c7+weHBn7slaEK2TQWeQShelte7p1vwW/bA2m1w6M0qew==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: consulting@xxxxxxxxxxx, sstabellini@xxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 12 Sep 2023 10:00:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12.09.2023 11:36, Simone Ballarin wrote:
> --- a/xen/arch/x86/efi/runtime.h
> +++ b/xen/arch/x86/efi/runtime.h
> @@ -1,3 +1,6 @@
> +#ifndef __X86_EFI_RUNTIME_H__
> +#define __X86_EFI_RUNTIME_H__
> +
>  #include <xen/domain_page.h>
>  #include <xen/mm.h>
>  #include <asm/atomic.h>
> @@ -17,3 +20,5 @@ void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t 
> l4e)
>      }
>  }
>  #endif
> +
> +#endif /* __X86_EFI_RUNTIME_H__ */

Leaving aside that I remain unconvinced of the usefulness of these in
(at least some) private headers, I think there's a naming issue to be
solved first: How do we distinguish guards of headers in xen/include/
and xen/arch/*/include/ from ones living elsewhere? If we don't set
forth a rule, the guard above might be re-used in a hypothetical
xen/arch/x86/include/asm/efi/runtime.h, with potentially interesting
effects. At a first glance it might work to simply omit "component"
identifiers, i.e. just use __RUNTIME_H__ here. Provided suitable
prefixes are used in all non-private headers. But I may of course be
overlooking pitfalls ...

Jan



 


Rackspace

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