[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |