Ping 2.
On 29/04/2020 15:04, Julien Grall wrote:
Hi,
Gentle ping. Any comments on the direction to take?
On 09/04/2020 10:28, Julien Grall wrote:
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
