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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEE8AC433F5 for ; Mon, 15 Nov 2021 14:11:42 +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 A916861B3D for ; Mon, 15 Nov 2021 14:11:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A916861B3D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.225944.390306 (Exim 4.92) (envelope-from ) id 1mmchf-0000eB-T7; Mon, 15 Nov 2021 14:11:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 225944.390306; Mon, 15 Nov 2021 14:11:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mmchf-0000e4-Pt; Mon, 15 Nov 2021 14:11:23 +0000 Received: by outflank-mailman (input) for mailman id 225944; Mon, 15 Nov 2021 14:11:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mmche-0000dy-9j for xen-devel@lists.xenproject.org; Mon, 15 Nov 2021 14:11:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mmchc-0001O1-1V; Mon, 15 Nov 2021 14:11:20 +0000 Received: from [54.239.6.189] (helo=[192.168.10.237]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mmchb-0004pw-R2; Mon, 15 Nov 2021 14:11:19 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=9Za1DzF3PkhnitzHrI17zIhpxZnD83lWppINSNqqwTo=; b=c9c7dbIlLWiLInmjnmiwQYXvMU 0FfjeZMYd1F5aHGGxbmUKOweHtDWjAGgDS5CogWuHkQsgpzmxFG3UO8xSpGHkoifb33XtsnUcO1jb vdTfOVO1mGkPvi3Z0n70qjvG00x77rpuTh2ZZxXdrNY+65Lh2M4Izr6VCp8EfoF9/tRg=; Message-ID: <06f83d83-382e-7ae7-551e-3f05a1cc3293@xen.org> Date: Mon, 15 Nov 2021 14:11:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 1/5] xen/domain: Remove function pointers from domain pause helpers To: Bertrand Marquis , Jan Beulich Cc: Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Stefano Stabellini , Volodymyr Babchuk , Andrew Cooper References: <20211111175740.23480-1-andrew.cooper3@citrix.com> <20211111175740.23480-2-andrew.cooper3@citrix.com> <02EF96BF-D2A6-4415-A6E9-B9511C18C895@arm.com> From: Julien Grall In-Reply-To: <02EF96BF-D2A6-4415-A6E9-B9511C18C895@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Bertrand, On 15/11/2021 11:23, Bertrand Marquis wrote: >> On 15 Nov 2021, at 10:55, Jan Beulich wrote: >> >> On 15.11.2021 11:23, Bertrand Marquis wrote: >>> Hi Jan, >>> >>>> On 15 Nov 2021, at 10:20, Jan Beulich wrote: >>>> >>>> On 15.11.2021 11:13, Bertrand Marquis wrote: >>>>>> On 11 Nov 2021, at 17:57, Andrew Cooper wrote: >>>>>> --- a/xen/common/domain.c >>>>>> +++ b/xen/common/domain.c >>>>>> @@ -1234,15 +1234,18 @@ int vcpu_unpause_by_systemcontroller(struct vcpu *v) >>>>>> return 0; >>>>>> } >>>>>> >>>>>> -static void do_domain_pause(struct domain *d, >>>>>> - void (*sleep_fn)(struct vcpu *v)) >>>>>> +static void _domain_pause(struct domain *d, bool sync /* or nosync */) >>>>> >>>>> Here you use comments inside the function definition. >>>>> I think this is something that should be avoided and in this specific case a >>>>> boolean sync is clear enough not to need to explain that false is nosing. >>>> >>>> While I agree the comment here isn't overly useful, I think ... >>>> >>>>>> @@ -1250,12 +1253,12 @@ static void do_domain_pause(struct domain *d, >>>>>> void domain_pause(struct domain *d) >>>>>> { >>>>>> ASSERT(d != current->domain); >>>>>> - do_domain_pause(d, vcpu_sleep_sync); >>>>>> + _domain_pause(d, true /* sync */); >>>>> Same here. >>>> >>>> ... comments like this one are pretty useful to disambiguate the plain >>>> "true" or "false" (without the reader needing to go look at the function >>>> declaration or definition). >>> >>> I agree with that but the comment here is useful, it could be added before >>> the call instead of inside it. >> >> Except the form Andrew has used is the one we've been using elsewhere >> for some time. > > I know I found some other examples and that why I say “should” and not must. > If other consider that this is the right way to go and should not be changed this > is ok with me Adding the comment after the parameter is a lot easier to read. What is Misra/FuSA trying to solve by preventing to comment just after the parameters? > but I wanted to make the comment as this could ease the work > with FuSa and Misra compliance in the future. This will need to be part of a larger discussion on how the community want to integrate FuSa/Misra rules. I do expect a few of the rules may be quite controversial to adopt (like the one above) and therefore we would need to discuss the pros/cons of them. Cheers, -- Julien Grall