[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH] xen: fixed violations of MISRA C:2012 Rule 3.1
First of all - please don't drop Cc-s when replying, unless you have a specific reason to. On 13.06.2023 11:56, nicola wrote: > On 13/06/23 10:27, Jan Beulich wrote: >> If you split this to 4 patches, leaving the URL proposal in just >> the cover letter, then I think this one change (with the adjustments) >> could go in right away. Similarly I expect the arm64/flushtlb.h >> change could be ack-ed right away by an Arm maintainer. > Ok. I do not understand what you mean by "leaving the URL proposal in > just the cover letter". Which URL? In your description you had a proposal to deviate the // occurring in URLs. The latest when splitting the patch, this doesn't belong into any of the patches anymore, but just in the cover letter. >> Here "propose" is appropriate in the description, as this is something >> the patch does not do. Further down, however, you mean to describe >> what the patch does, not what an eventual patch might do. >> > To my knowledge, there is not a standard format to define a project > deviation for a certain MISRA rule in Xen right now (this can also be > discussed in a separate thread). To clarify, I meant to describe why I > wasn't addressing these violations in the patch (they are the vast > majority, but they do not have any implication w.r.t. functional safety > and can therefore be safely deviated with an appropriate written > justification). And as said, for what you're not doing in the patch, using "propose" is quite fine (as per above, whether that actually belongs in the description is another question). I view the word as inapplicable though when you describe what you're actually doing in a patch. But I'm not a native speaker, so I may be wrong here. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |