Re: [PATCH v2 09/10] xsm: expand the function related macros in dummy.h

From: Jan Beulich <jbeulich@suse.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 09/10] xsm: expand the function related macros in dummy.h
Date: Tue, 3 Aug 2021 09:23:07 +0200	[thread overview]
Message-ID: <75b2e3a8-4e6e-c73e-9e35-8f1c9f501b9d@suse.com> (raw)
In-Reply-To: <0c944d5f-cc79-4df9-9531-cb918aef8fe8@apertussolutions.com>

On 24.07.2021 22:07, Daniel P. Smith wrote:
> On 7/16/21 3:34 AM, Jan Beulich wrote:
>> On 12.07.2021 22:32, Daniel P. Smith wrote:
>>> With the elimination of switching how dummy.h gets included, the function
>>> declaration macros are no longer necessary. This commit expands them out to the
>>> only value for which they will ever be set. This results in function
>>> declaration lengths changing and since some definitions did not even follow the
>>> 80 column wrapping style, all function definitions were aligned with the
>>> predominate style found in core hypervisor code.
>>
>> I'm afraid this last half sentence is quite far from true:
> 
> I would disagree since I know I went through the frustration of trying
> to find a discernible consistency in the files in common/ in the end I
> settled on following common/memory.c since it seemed to have the most
> uniform, it had only a couple of anomalies, as opposed to other files
> where indentation was varied throughout.
> 
>>> @@ -82,43 +79,43 @@ static always_inline int xsm_default_action(
>>>      }
>>>  }
>>>  
>>> -static XSM_INLINE void dummy_security_domaininfo(struct domain *d,
>>> +static inline void dummy_security_domaininfo(struct domain *d,
>>>                                      struct xen_domctl_getdomaininfo *info)
>>
>> Padding wasn't good here before, but you clearly do not change it to
>> either of the forms we agreed on as being the goal for consistency:
> 
> Then that agreement should be document as CODING_STYLE only states:
> 
> 
> Line Length
> -----------
> 
> Lines should be less than 80 characters in length.  Long lines should
> be split at sensible places and the trailing portions indented.
> 
> 
> I found that in common/memory.c the predominate style was to align
> parameters with the first parameter when wrapping, which is what I
> followed. In this specific case when I wrapped the second parameter to
> make the line less than 80 chars (an explicit rule in CODING_STYLE) and
> attempted to align with the first paramter resulted in the line
> exceeding 80 chars. Since the only hard rule is lines must be less than
> 80, I decreased the indent by enough characters for the line to be less
> than 80 to be in line with CODING_STYLE since it only calls for sensible
> splits that are indented.
> 
>> static inline void dummy_security_domaininfo(struct domain *d,
>>                                              struct xen_domctl_getdomaininfo *info)
>>
>> or
>>
>> static inline void dummy_security_domaininfo(
>>     struct domain *d,
>>     struct xen_domctl_getdomaininfo *info)
>>
> 
> I will align to the second, even though I find it annoying to switch
> alignment styles, since the first would be in violation of CODING_STYLE
> sine the second line would exceed 80 chars

I guess you nevertheless realize that this 2nd form is precisely to
overcome the problem with otherwise exceeding the 80 chars limit,
while at the same time making sure the indentation doesn't end up
entirely random then?

As to extending ./CODING_STYLE - I've had rather bad experience
with attempts to do so, with my two most recent patches to that effect
just having had their 2nd anniversary without getting any feedback
moving things forward (despite, unlike in some earlier instances, the
proposed changes not looking overly controversial to me).

Coincidence or not, just a few days after my submission Volodymyr
submitted a patch making an attempt to document function parameter
indentation [1]. While the patch as is had some comments, it didn't
seem like it was controversial either. Yet nothing has since made it
in.

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2019-07/msg02440.html