On 07.09.2021 16:55, Daniel P. Smith wrote: > On 9/7/21 10:27 AM, Jan Beulich wrote: >> On 07.09.2021 16:09, Daniel P. Smith wrote: >>> On 9/7/21 9:50 AM, Jan Beulich wrote: >>>> On 07.09.2021 15:41, Daniel P. Smith wrote: >>>>> On 9/6/21 2:17 PM, Andrew Cooper wrote: >>>>>> On 03/09/2021 20:06, Daniel P. Smith wrote: >>>>>>> --- a/xen/include/xsm/dummy.h >>>>>>> +++ b/xen/include/xsm/dummy.h >>>>>>> @@ -69,8 +69,9 @@ void __xsm_action_mismatch_detected(void); >>>>>>> >>>>>>> #endif /* CONFIG_XSM */ >>>>>>> >>>>>>> -static always_inline int xsm_default_action( >>>>>>> - xsm_default_t action, struct domain *src, struct domain *target) >>>>>>> +static always_inline int xsm_default_action(xsm_default_t action, >>>>>>> + struct domain *src, >>>>>>> + struct domain *target) >>>>>> >>>>>> The old code is correct. We have plenty of examples of this in Xen, and >>>>>> I have been adding new ones when appropriate. >>>>>> >>>>>> It avoids squashing everything on the RHS and ballooning the line count >>>>>> to compensate. (This isn't a particularly bad example, but we've had >>>>>> worse cases in the past). >>>>> >>>>> Based on the past discussions I understood either is acceptable and find >>>>> this version much easier to visually parse myself. With that said, if >>>>> the "next line single indent" really is the preferred style by the >>>>> maintainers/community, then I can convert all of these over. >>>> >>>> I guess neither is the "preferred" style; as Andrew says, both are >>>> acceptable and both are in active use. I guess the rule of thumb is: >>>> The longer what's left of the function name, the more you should >>>> consider the style that you change away from. >>>> >>>> Anyway, in the end I guess the request for style adjustments was >>>> mainly to purge bad style, not to convert one acceptable form to >>>> another. Converting the entire file to the same style is of course >>>> fine (for producing a consistent result), but then - as per above - >>>> here it would more likely be the one that in this case was already >>>> there. >>> >>> Understood, I will respin with all the function defs to align with the >>> "next line single indent" style, though it would be helpful for >>> clarification on this style exactly. Do you always wrap all args if one >>> extends past 80 col or is there a rule for when some should remain on >>> the first line (function def line)? >> >> I don't think that aspect has been discussed. I would say >> >> void sufficiently_long_attribute test(unsigned int x, unsigned int y, >> unsigned int z, void *p); >> >> is as acceptable as >> >> void sufficiently_long_attribute test(unsigned int x, >> unsigned int y, >> unsigned int z, >> void *p); >> >> with a slight preference to the former. > > Apologies, I was referring to this style which I am understanding is a > little more preferred > > void short_function_name( > struct really_long__struct_name *x, > struct really_long__struct_name *y, unsigned int z, void *p); > > vs > > void short_function_name(struct really_long__struct_name *x, > struct really_long__struct_name *y, unsigned int z, void *p);
This latter style is not supposed to be used. Jan
