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

Re: [PATCH 1/5] xen/domain: Remove function pointers from domain pause helpers


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Mon, 15 Nov 2021 14:45:44 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8pfftpuK/NNpwJ+kb4m/cNWuDnpgX7GSos0apNFZI7Y=; b=m4ixxobe6gYgFYMBL0D7G29DG13diJZbHMBQO0k994sejF+BjlU2LTlh74lUIdzrzetSW8hUlCWR29Z9lcbHdBWCiWLKuS2sWrreVvZcFJ2dkaoXV8lOgejMM6euOwlJmBlPClw2zzuWXwlcCk3VBC6S7rKtYg27tBzXYcKvf7eud/hk+uR4DHCnpb4xT4XcWCWLHSJorLoBklqSys7yhL5jhUNSUCl3sju6miZiVTxfWI95bKj4FGDUqwlO01ogreOuT/UAKz9GHh/pfDbbXhLU1J9Xc3W+iEG9kbzhadQ9gAhaVMR7SQ4EO6LKF6RbYLpQr8CxE034OZTIYcQ27g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VnyEFYfpPD+lVU+glx1Yc8x1YMB2AIe3xX9ZRoVSxRZutZF3XFYEI+9C7VoBlMP55rGqWtO+30VidCAekTgl/TpX8ILUstVppYQHKRD1y3UVXcKYbQIVNbVTFiiIir8fW604KBvva0+hPZ1kUBIRGdjT1o2qrGlig0S12/Stk3bNucOecI5GQzNee2foVS7CBOYQ1KWrA/Dp6tp3LKrZ3qSZ3Fhj9oHIIvYUZ5mmzeowaTP6Oa3Re7MVNeFGAMvSD8PHA4xedP8V2bMLL0smEuygsTMGu/+8PltA436hJmdKT+JES27KaJx0SfOD66PC2Zp0kKFtQ8fZyLcQrSRn5g==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Mon, 15 Nov 2021 14:46:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHX1yW51DCh4Kb6WkC+olJaqOqcEawEZHMAgAACF4CAAADoAIAACOmAgAAHu4CAAC7ugIAACaAA
  • Thread-topic: [PATCH 1/5] xen/domain: Remove function pointers from domain pause helpers

Hi,

> On 15 Nov 2021, at 14:11, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On 15/11/2021 11:23, Bertrand Marquis wrote:
>>> On 15 Nov 2021, at 10:55, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 15.11.2021 11:23, Bertrand Marquis wrote:
>>>> Hi Jan,
>>>> 
>>>>> On 15 Nov 2021, at 10:20, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> 
>>>>> On 15.11.2021 11:13, Bertrand Marquis wrote:
>>>>>>> On 11 Nov 2021, at 17:57, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>>>>>> 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?

I do not think Misra is always trying to prevent “bugs”, sometimes it is just 
trying to make
the code easier to read and review by making it always look the same. Here is 
to saying that
this should not be done but that comment should be written one or several lines 
using /* */ form.

> 
>> 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.

I definitely think this will require a discussion and maybe some more 
explanation from us on why.
Your comment asking “What is prevented” is interesting and I will try to keep 
that in mind when we start the discussion.


Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall


 


Rackspace

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