On 28.02.2023 08:36, Xenia Ragiadakou wrote: > > On 2/27/23 17:25, Jan Beulich wrote: >> On 24.02.2023 19:50, Xenia Ragiadakou wrote: >>> --- /dev/null >>> +++ b/xen/arch/x86/hvm/vmx/pi.h >>> @@ -0,0 +1,78 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +/* >>> + * pi.h: VMX Posted Interrupts >>> + * >>> + * Copyright (c) 2004, Intel Corporation. >>> + */ >>> + >>> +#ifndef __X86_HVM_VMX_PI_PRIV_H__ >>> +#define __X86_HVM_VMX_PI_PRIV_H__ >> >> I can see that you need something to disambiguate the two vmx.h. But >> here you don't need the PRIV infix, do you? Even in the private vmx.h >> I'd like to ask to consider e.g. __VMX_H__ as the guard (and then >> __PI_H__ here), rather than one which doesn't really match the >> filename. > > I do agree that adding _PRIV_ is off target. > For the purpose of disambiguation, the header guards need to conform to > a well specified pattern guaranteed not to be used for anything else. > For that reason I would suggest the guard to include the path, not just > the file name.
But as we see the path can be ambiguous, unless all non-private headers had an "INCLUDE" infix. Hence my proposal would be no path at all for private headers, and path (as we frequently but perhaps not consistently have it) for non-private ones. > In any case, the pattern that is used to generate the header guards > should be mentioned in the coding style doc. Perhaps. Jan
