Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in xen/guest_access.h

[Julien Grall <julien@xen.org>]

On 09/04/2020 09:06, Jan Beulich wrote:
> On 09.04.2020 10:01, Julien Grall wrote:
>> Hi,
>>
>> On 09/04/2020 07:30, Jan Beulich wrote:
>>> On 09.04.2020 00:05, Julien Grall wrote:
>>> I don't see why a new port may not also want
>>> to go that route instead of the x86/Arm one.
>> I could accept that someone would want to reinvent a new ABI
>> from scratch for just an hypothetical new arch. However it would
>> be quite an effort to reinvent XEN_GUEST_HANDLE(). The chance is
>> RISC-V is only going to re-use what Arm did as Arm already did
>> with x86.
>>
>> I would like to avoid to introduce a new directory asm-generic
>> with just one header in it. Maybe you have some other headers in
>> mind?
> 
> I recall having wondered a few times whether we shouldn't use this
> concept elsewhere. One case iirc was bitops stuff. Looking over
> the Linux ones, some atomic and barrier fallback implementations
> may also sensibly live there, and there are likely more.

In theory it makes sense but, in the current state of Xen, 'asm-generic' 
means they are common to Arm and x86. This is basically the same 
definition as for the directory 'xen'. So how do you draw a line which 
files go where?

To be honest, I don't think we can draw a line without a 3rd 
architecture. So I would recommend to wait until then to create an 
asm-generic directory.

Meanwhile, I still think the consolidation in xen/ is useful as it makes 
easier to maintain. It is also going to make easier for RISCv (or a new 
arch) as they don't have to worry about duplication (if any).

In the event they decide to purse their own route, then it is not going 
to be a massive pain to move part of xen/guest_access.h in 
asm-generic/guest_access.h and include the latter from {xen, asm} 
/guest_access.h.

Cheers,


-- 
Julien Grall