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

Re: [PATCH 2/7] xen/arm: Wrap shared memory mapping code in one function


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Wed, 8 May 2024 08:33:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=fHocSXdyfuCzYVEwjGoiSjVB03rI4Z4IWRghwYVOdPM=; b=WvlHi9gXtaVPwiyAeNjo5kmmH2sMMJhdWJH6upibiUjri1wrA5ufVWOYyEkYiuv0aUMxEYAspQaalVSy/SXqwyuPBdLcoQfHACyzQ9YTJrOSlOQNueD+0i08Tk7s+XQYgLKt8K2rM/nMrj+vgKOE5LDdSZsQS3vshFVFWEzP/yO0r71cmLAG6fBhI/+O33iYRezaVxFa2ppWCJIN9QfhG8/F+8wfXaQ603MJATuVZQZG8MsjD8qzrBYd2eb56t//K20BaxQirRjly0FXZeDnAZ7UDn8Ef/NQSwqXgZY/rNUNT7FhzV81sepGaXRR1fuFj76j1rF+pcjMMSGbmTTHiQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gO60bE+H/DC3jZl4CDEnzU+Eg4fQ9nEMgQb6wgKUhKHAnJ24xutCIWsyGTrvPt7zkh3QfzgXu05qKyzNNkcylMasBBZiJv5EbjsMAa1bEDRLc2/Q/RNjzyODHJuTNi6PSoJgkAk/6OJA0bTKnJNqQQzWePT//QHVWffsB2Tp6f0JEFe0nUqIQx6rZV7Eb+imfVB9D1VlvkRmGdBkji8Zyf139+NX1ieGebr2N4lUx83fSgKkroHbEIPjVCNLZlB9f1JeQUBYzutO+Fu/Mkq/wxCLeSv02EnvihEpoE1j3HWdH9l7GmexlXTlb5cIYXD3/GzJ3WwkHmzxuPl9GkvjiA==
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 08 May 2024 06:33:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 07/05/2024 16:15, Luca Fancellu wrote:
> 
> 
> Hi Michal,
> 
> 
>>>>>
>>>>> int __init process_shm(struct domain *d, struct kernel_info *kinfo,
>>>>>                       const struct dt_device_node *node)
>>>>> {
>>>>> @@ -249,32 +290,10 @@ int __init process_shm(struct domain *d, struct 
>>>>> kernel_info *kinfo,
>>>>>        if ( dt_property_read_string(shm_node, "role", &role_str) == 0 )
>>>>>            owner_dom_io = false;
>>>> Looking at owner_dom_io, why don't you move parsing role and setting 
>>>> owner_dom_io accordingly to handle_shared_mem_bank()?
>>>
>>> I think I wanted to keep all dt_* functions on the same level inside 
>>> process_shm, otherwise yes, I could
>>> pass down shm_node and do the reading of role_str in 
>>> handle_shared_mem_bank, or I could derive
>>> owner_dom_io from role_str being passed or not, something like:
>>>
>>> role_str = NULL;
>>> dt_property_read_string(shm_node, "role", &role_str)
>>>
>>> [inside handle_shared_mem_bank]:
>>> If ( role_str )
>>>    owner_dom_io = false;
>>>
>>> And pass only role_str to handle_shared_mem_bank.
>>>
>>> Is this comment to reduce the number of parameters passed? I guess it’s not 
>>> for where we call
>> In this series as well as the previous one you limit the number of arguments 
>> passed to quite a few functions.
>> So naturally I would expect it to be done here as well. owner_dom_io is used 
>> only by handle_shared_mem_bank, so it makes more sense to move parsing to 
>> this
>> function so that it is self-contained.
> 
> Ok I will, just to be on the same page here, you mean having 
> dt_property_read_string inside handle_shared_mem_bank?
> Or the above example would work for you as well? That one would have role_str 
> passed instead of shm_node.
I'm ok with the solution above to pass role_str.

~Michal



 


Rackspace

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