From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C89CC4338F for ; Sat, 24 Jul 2021 20:08:06 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ADD1A60E96 for ; Sat, 24 Jul 2021 20:08:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ADD1A60E96 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=apertussolutions.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.160497.295087 (Exim 4.92) (envelope-from ) id 1m7Nvu-0004jC-4O; Sat, 24 Jul 2021 20:07:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 160497.295087; Sat, 24 Jul 2021 20:07:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m7Nvu-0004j5-1I; Sat, 24 Jul 2021 20:07:38 +0000 Received: by outflank-mailman (input) for mailman id 160497; Sat, 24 Jul 2021 20:07:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m7Nvs-0004iz-4U for xen-devel@lists.xenproject.org; Sat, 24 Jul 2021 20:07:36 +0000 Received: from sender4-of-o51.zoho.com (unknown [136.143.188.51]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c85cf08c-ecba-11eb-955d-12813bfff9fa; Sat, 24 Jul 2021 20:07:34 +0000 (UTC) Received: from [10.10.1.24] (static-72-81-132-2.bltmmd.fios.verizon.net [72.81.132.2]) by mx.zohomail.com with SMTPS id 1627157248999314.5502574414819; Sat, 24 Jul 2021 13:07:28 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c85cf08c-ecba-11eb-955d-12813bfff9fa ARC-Seal: i=1; a=rsa-sha256; t=1627157251; cv=none; d=zohomail.com; s=zohoarc; b=A1GPZlPK1lwD0fdf/STb5XdFLWt8KnH18vcp59gXU5L8lpuXZ37P3o+qMXCc5jsiryES84MvwjVkvi8955u+5LIurJnM0J7MZcVDFksiTXjCnPew01aUpzPNI2BW0z1mklFbUgpziGbvuCCFPkSfx6mkj52F7Mm8rjM1Gs0ESfo= 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-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@apertussolutions.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1627157251; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=sMyL52ngESrAeHbnk3UHc7t7QxjbnTa7tbz4U17eyBU=; b=LodJJ94dzxkzsIu2mMTjpaIbNJkjx+Dyc+l6VnmkmFy1gseg5rBhsiWUxHA7TM4G vktJu0VHiAqrT8MH8r2U6/KJc7yqFfg2WVEr6P0fPNYH8Rj0XZve5Rpb/pJPeRKNBdf zNAAo/WktF+07riOXTBkYqZ4OXdw1lJFRnSQU9Gs= To: Jan Beulich Cc: Daniel De Graaf , xen-devel@lists.xenproject.org References: <20210712203233.20289-1-dpsmith@apertussolutions.com> <20210712203233.20289-10-dpsmith@apertussolutions.com> <34c71bc9-18e8-08cd-d55f-9f5f97bde91e@suse.com> From: "Daniel P. Smith" Subject: Re: [PATCH v2 09/10] xsm: expand the function related macros in dummy.h Message-ID: <0c944d5f-cc79-4df9-9531-cb918aef8fe8@apertussolutions.com> Date: Sat, 24 Jul 2021 16:07:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <34c71bc9-18e8-08cd-d55f-9f5f97bde91e@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ZohoMailClient: External 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 to uint_t, to bring this file > better in line with ./CODING_STYLE? Sure. v/r, dps