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

Re: [RFC PATCH 17/17] CODING_STYLE: Add a section on header guards naming conventions


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 19 Jul 2024 11:05:07 +0200
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Alessandro Zucchelli <alessandro.zucchelli@xxxxxxxxxxx>, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 19 Jul 2024 09:05:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.07.2024 00:01, Stefano Stabellini wrote:
> On Thu, 18 Jul 2024, Jan Beulich wrote:
>> On 18.07.2024 01:02, Stefano Stabellini wrote:
>>> On Wed, 17 Jul 2024, Jan Beulich wrote:
>>>> On 17.07.2024 02:20, Stefano Stabellini wrote:
>>>>> On Tue, 16 Jul 2024, Jan Beulich wrote:
>>>>>> On 16.07.2024 02:43, Stefano Stabellini wrote:
>>>>>>> On Mon, 15 Jul 2024, Jan Beulich wrote:
>>>>>>>> On 13.07.2024 00:38, Stefano Stabellini wrote:
>>>>>>>>> On Wed, 3 Jul 2024, Jan Beulich wrote:
>>>>>>>>>> I further have to note that, as indicated during the earlier 
>>>>>>>>>> discussion,
>>>>>>>>>> I still cannot see how occasional ambiguity is going to be dealt 
>>>>>>>>>> with.
>>>>>>>>>> IOW from the rules above two different headers could still end up 
>>>>>>>>>> with
>>>>>>>>>> the same guard identifier.
>>>>>>>>>
>>>>>>>>> Maybe something like this?
>>>>>>>>>
>>>>>>>>> "In the event of naming collisions, exceptions to the coding style may
>>>>>>>>> be made at the discretion of the contributor and maintainers."
>>>>>>>>
>>>>>>>> Hmm, maybe I wasn't clear enough then. My take is that the scheme 
>>>>>>>> should
>>>>>>>> simply not allow for possible collisions. Neither the contributor nor 
>>>>>>>> the
>>>>>>>> reviewer may spot such a collision, and it may therefore take until the
>>>>>>>> first full scan that one is actually noticed. Which I consider too late
>>>>>>>> in the process, even if we already were at the point where commits were
>>>>>>>> checked pre-push.
>>>>>>>
>>>>>>> Looking at the proposal, copy/pasted here for convenience:
>>>>>>>
>>>>>>> - private headers -> <dir>_<filename>_H
>>>>>>> - asm-generic headers -> ASM_GENERIC_<filename>_H
>>>>>>>     - #ifndef ASM_GENERIC_X86_PERCPU_H
>>>>>>>       #define ASM_GENERIC_X86_PERCPU_H
>>>>>>>       //...
>>>>>>>       #endif /* ASM_GENERIC_X86_PERCPU_H */
>>>>>>> - arch/<architecture>/include/asm/<subdir>/<filename>.h -> 
>>>>>>> ASM_<architecture>_<subdir>_<filename>_H
>>>>>>>     - #ifndef ASM_X86_DOMAIN_H
>>>>>>>       #define ASM_X86_DOMAIN_H
>>>>>>>       //...
>>>>>>>       #endif /* ASM_X86_DOMAIN_H */
>>>>>>> - xen/include/xen/<filename>.h -> XEN_<filename>_H
>>>>>>> - xen/include/xen/<subdir>/<filename>.h -> XEN_<subdir>_<filename>_H
>>>>>>>
>>>>>>>
>>>>>>> The only possibility for collision that I can see is from the first
>>>>>>> point:
>>>>>>>
>>>>>>> - private headers -> <dir>_<filename>_H
>>>>>>
>>>>>> I don't think this is the only possibility of collisions. The 
>>>>>> <subdir>_<filename>
>>>>>> parts can similarly cause problems if either of the two involved names 
>>>>>> contains
>>>>>> e.g. a dash (which would need converting to an underscore) or an 
>>>>>> underscore. To
>>>>>> avoid this, the name separators (slashes in the actual file names) there 
>>>>>> may need
>>>>>> representing by double underscores.
>>>>>
>>>>> I am OK with you two underscores as name separator (slashes in the
>>>>> actual file names). Would you do it for all levels like this?
>>>>>
>>>>> - arch/arm/arm64/lib/something.h -> ARM__ARM64__LIB__SOMETHING_H
>>>>> - arch/arm/arm32/lib/something.h -> ARM__ARM32__LIB__SOMETHING_H
>>>>> - arch/x86/lib/something.h -> X86__LIB__SOMETHING_H
>>>>>
>>>>>
>>>>> I think it is better than the below:
>>>>>
>>>>> - arch/arm/arm64/lib/something.h -> ARM_ARM64__LIB__SOMETHING_H
>>>>> - arch/arm/arm32/lib/something.h -> ARM_ARM32__LIB__SOMETHING_H
>>>>> - arch/x86/lib/something.h -> X86_LIB__SOMETHING_H
>>>>
>>>> Hmm, maybe it's indeed better to do it entirely uniformly then.
>>>
>>>
>>> Do we have agreement on the naming convention then? 
>>>
>>>
>>> - private headers -> <dir>__<filename>__H
>>>     - arch/arm/arm64/lib/something.h -> ARM__ARM64__LIB__SOMETHING_H
>>>     - arch/arm/arm32/lib/something.h -> ARM__ARM32__LIB__SOMETHING_H
>>>     - arch/x86/lib/something.h -> X86__LIB__SOMETHING_H
>>>
>>> - asm-generic headers -> ASM_GENERIC_<filename>_H
>>>     - include/asm-generic/percpu.h -> ASM_GENERIC_X86_PERCPU_H
>>>
>>> - arch/<architecture>/include/asm/<subdir>/<filename>.h -> 
>>> ASM_<architecture>_<subdir>_<filename>_H
>>>     - arch/x86/include/asm/domain.h -> ASM_X86_DOMAIN_H
>>>
>>> - include/xen -> XEN_<filename>_H
>>>     - include/xen/percpu.h -> XEN_PERCPU_H
>>>
>>>
>>> Or do you prefer the double underscore __  in all cases?
>>
>> It's not so much prefer, but a requirement if we want to be future proof.
>> Even for ASM_GENERIC_* that'll be needed, as your outline above simply
>> doesn't mention the (future) case of there being subdir-s there (see how
>> Linux already has some). Imo the question doesn't even arise for XEN_*,
>> as xen/ has subdir-s already.
> 
> OK. So it becomes:
> 
> - private headers -> <dir>__<filename>_H
>     - arch/arm/arm64/lib/something.h -> ARM__ARM64__LIB__SOMETHING_H
>     - arch/arm/arm32/lib/something.h -> ARM__ARM32__LIB__SOMETHING_H
>     - arch/x86/lib/something.h -> X86__LIB__SOMETHING_H
> 
> - asm-generic headers -> ASM_GENERIC__<filename>_H
>     - include/asm-generic/percpu.h -> ASM_GENERIC__X86__PERCPU_H

Nit: There's still a stray _X86_ in here.

Jan

> - arch/<architecture>/include/asm/<subdir>/<filename>.h -> 
> ASM__<architecture>__<subdir>__<filename>_H
>     - arch/x86/include/asm/domain.h -> ASM__X86__DOMAIN_H
> 
> - include/xen -> XEN__<filename>_H
>     - include/xen/percpu.h -> XEN__PERCPU_H
> 
> If we have found agreement then Alessandro could send an update




 


Rackspace

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