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

Re: [PATCH] xen/arm: Move static event channel feature to a separate module


  • To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Wed, 29 Nov 2023 19:09:40 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org 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=Vex1tmOM2sMcRrcgze6k7ZYriWYb8FsjPwjP/Rioo5k=; b=OnUVuFFk3Rhbnl26nSQaa7BGuwo95eVEy8C/QdnC9K8phTcw1TRnCFWhEkeRBMxamJQorMD20pzPecxDnE4V2m1VNETgrpbtVZdHgHBLJKGFZHBhozKYhiIBhyJcQTPwROYzeA3LK/i+LVcQwjgORF3qv2jveO0lIftPPwjD3Sn9cGiwyiqLXfW9Ef9YEcbydV71PEA2PYESHWGXwKYsmSdYjzDLtoGyQiRXfc0MjihDVq+Qvt5rvWaGzWvWQhbnMzPmAM0C75aEvYRarHnWhi8z6iNGasA4TY4s+A7lnVF1MOLzXz63oZIRN28vscCRAiSzBQWL+3x2eQn3Hsz50A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ckR2xVQ22oYl1p2qjoMPMZpKgl0pPozCbwEKJXMKzO+uO35YLlRXdR1XUJS8oI5MjPgsTJ2oMoUN4qWyHR57wAUdvyzneuGtIB7KWj2cW9U0E7ALSigQNHE6uZ5lgI21WUPjVEx62mfvzLbMsctY7dLYFNBImK31cnUjCI9R/6Gqyy5k6wNwZHhYQdMw68uQsELSMyplWOemBfChI63Add6dnYv4XSkQBLS6AgRFgD6R4djH5wB0UBdJYgOfQMWwe55N3phRvC6Pax3pNNd/WZBHPQcY5fMa9iSjvCmunHm5TVmjJfg7ChsC+lezaHnZXG/hBgIQuOuj5AUbfNBw8w==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 29 Nov 2023 18:09:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 29/11/2023 18:54, Julien Grall wrote:
> 
> 
> Hi Michal,
> 
> On 29/11/2023 18:41, Michal Orzel wrote:
>> On 29/11/2023 18:17, Julien Grall wrote:
>>> That said, I could settle on defining the two helpers in the *.c
>>> directly because they are not meant to be used outside of a single *.c.
>>>
>>> Simarly...
>>>
>>>> diff --git a/xen/arch/arm/include/asm/static-evtchn.h 
>>>> b/xen/arch/arm/include/asm/static-evtchn.h
>>>> new file mode 100644
>>>> index 000000000000..472673fae345
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/include/asm/static-evtchn.h
>>>> @@ -0,0 +1,41 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>> +
>>>> +#ifndef __ASM_STATIC_EVTCHN_H_
>>>> +#define __ASM_STATIC_EVTCHN_H_
>>>> +
>>>> +#ifdef CONFIG_STATIC_EVTCHN
>>>> +
>>>> +#include <xen/device_tree.h>
>>>> +
>>>> +#define STATIC_EVTCHN_NODE_SIZE_CELLS 2
>>>
>>> ... this used to be defined in domain_build.c. AFAICT the only use is
>>> now in static-evtchn.c. So why is it defined in the header?
>>>
>>> If this is moved in the *.c, then the header static-evtchn.h would only
>>> contain alloc_static_evtchn(). This could be moved in domain_build.h or
>>> setup.h (I don't have any preference).
>> Apart from a prototype, we still need a stub. Therefore I would prefer to 
>> still have a header (will
>> be needed for future upgrades e.g. port exposure in fdt) and move the 
>> prototype and a stub there (the macro
>> I can move to *.c). It just looks better for me + we reduce ifdefery in 
>> domain_build/setup.h.
>> Would you be ok with that?
> 
> I don't much like headers containing just one prototype. But I can live
> with them if you think more will be added.
I can at least think of adding support for discovering static ports.
Thank you for meeting me halfway.

~Michal



 


Rackspace

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