[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 24 Jul 2021 16:07:27 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1627157251; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=sMyL52ngESrAeHbnk3UHc7t7QxjbnTa7tbz4U17eyBU=; b=PcqyafkprxQnwcyqkILa8dg7kWHs4k5N6O3qnvZnYQJ+ayq/nWIJOuBBkh1p+zLTckeFKsmvnhkPZxTXX6TXC5s4Q4jC+ks69SP0TdOO90X5EahSwq8rIy2bw0aiD7Vl4nLwEGxH/wJVTEDBzljdBqYPnTlZWLl+ImIefHA+0aA=
  • Arc-seal: i=1; a=rsa-sha256; t=1627157251; cv=none; d=zohomail.com; s=zohoarc; b=A1GPZlPK1lwD0fdf/STb5XdFLWt8KnH18vcp59gXU5L8lpuXZ37P3o+qMXCc5jsiryES84MvwjVkvi8955u+5LIurJnM0J7MZcVDFksiTXjCnPew01aUpzPNI2BW0z1mklFbUgpziGbvuCCFPkSfx6mkj52F7Mm8rjM1Gs0ESfo=
  • Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 24 Jul 2021 20:07:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

>> -static XSM_INLINE int dummy_domain_create(XSM_DEFAULT_ARG struct domain *d, 
>> u32 ssidref)
>> +static inline int dummy_domain_create(struct domain *d, u32 ssidref)
> When you have to touch lines anyway, may I suggest that you also take
> the opportunity and convert u<N> to uint<N>_t, to bring this file
> better in line with ./CODING_STYLE?





Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.