|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
> On 2 Nov 2023, at 11:53, Jan Beulich <jbeulich@xxxxxxxx> wrote: > > 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 will start a separate thread, referring to this serie, with all the maintainers and I will push a number of parameters at the time, starting from the one that already enforces the content of the coding style, with explanation for them. > >> 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. Sure, I will start from the “straightforward” which I mean the one that I think are less controversial, for example here I know well that we use C99, but clang-format was not really meant for C, it’s more Cpp oriented, however C++03 is the value used by Linux so I guess it can be fine also for us. Anyway as I said, I can start another thread with a few parameters that we can analyze each time. > >> ================================================================================ >> 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. So here I meant that these parameters are only tuning the algorithm, so their value is not something enforcing a rule, so they are in some way “bending” some of them but their effect is visible mostly in conjunction with the overall computation of every rule. But of course we are going to discuss also them, it’s just that I don’t feel there might be disagreements on them. > > Jan
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |