Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.11.2023 12:41, Luca Fancellu wrote:
>> On 2 Nov 2023, at 09:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 31.10.2023 14:23, Luca Fancellu wrote:
>>> Add a clang format configuration for the Xen Hypervisor.
>>>
>>> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
>>> ---
>>> xen/.clang-format | 693 ++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 693 insertions(+)
>>> create mode 100644 xen/.clang-format
>>
>> I think this needs splitting and every setting then individually correlating
>> with what we have in ./CODING_STYLE. That would entail extending 
>> ./CODING_STYLE
>> by anything not presently written down, but intended to be checked for.
> 
> Do you mean introducing one parameter for each patch with the corresponding 
> entry in
> CODING_STYLE?
> 
> It would make sense, however there are 116 parameters, from those I think at 
> least 56 needs
> to have a corresponding entry in CODING_STYLE (maybe in the end they will be 
> less, but I don’t expect
> them to be less than 40), so given the amount of patches, I’m afraid to flood 
> the mailing list.

Some grouping may certainly make sense, for related settings. What I'm
completely lost with the present submission is which of the settings
merely enforce existing content of ./CODING_STYLE, and which ones
(silently) impose new rules which everyone may agree with, but also may
not.

> I was thinking we could discuss them in chunks and update the serie during 
> time, we could put in this
> patch also the update to the CODING_STYLE file. Something like the MISRA rule 
> acceptance, what
> do you think? Shall we do the discussion by ML or by meetings? Every time I 
> could bring up a number
> of parameters and update the serie when the discussion on them is finished.

Afaic - email if at all possible. The more that, considering past
attempts to extend ./CODING_STYLE, for some items it may be close to
impossible to reach agreement.

> This is my breakdown:
> 
> 116 total configurables
> 
> ================================================================================
> 13 straightforward

What exactly do you qualify as such?

> AttributeMacros:
>   -[...]
> 
> ColumnLimit: 80
> 
> IndentWidth: 4
> 
> Language: Cpp
> 
> MacroBlockBegin: '^PLATFORM_START|^DT_DEVICE_START|^ACPI_DEVICE_START'
> 
> MacroBlockEnd: '^PLATFORM_END|^DT_DEVICE_END|^ACPI_DEVICE_END'

Without explanation it is, for example, not clear to me what these two
settings are about. Which includes me not understanding why these
identifiers are (apparently) special in some specific way.

> Standard: C++03

I don't consider this "straightforward" at all. Only C99 could be deemed
straightforward here, imo.

> ================================================================================
> 10 don't really need a discussion
> 
> PenaltyBreakAssignment: 30
> 
> PenaltyBreakBeforeFirstCallParameter: 30
> 
> PenaltyBreakComment: 10
> 
> PenaltyBreakFirstLessLess: 0
> 
> PenaltyBreakOpenParenthesis: 100
> 
> PenaltyBreakString: 10
> 
> PenaltyExcessCharacter: 100
> 
> PenaltyIndentedWhitespace: 0
> 
> PenaltyReturnTypeOnItsOwnLine: 60
> 
> CommentPragmas: '^ IWYU pragma:'

Like with the "straightforward" ones above, without knowing what these
affect (or whether some simply don't affect us at all, and hence could
be set to any value) I can't follow the "don't really need a discussion"
qualification.

Jan