Hi Julien, > On 12 Apr 2024, at 15:53, Julien Grall <julien.grall....@gmail.com> wrote: > > > > On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini <sstabell...@kernel.org> > wrote: > On Wed, 10 Apr 2024, Julien Grall wrote: > > On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini > > <stefano.stabell...@amd.com> wrote: > > xen_ulong_t is widely used in public headers. > > > > Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com> > > --- > > > > Given that xen_ulong_t is used in public headers there could be a > > better > > place for documenting it but this was the most straightforward to add. > > --- > > docs/misra/C-language-toolchain.rst | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/docs/misra/C-language-toolchain.rst > > b/docs/misra/C-language-toolchain.rst > > index 5ddfe7bdbe..7a334260e6 100644 > > --- a/docs/misra/C-language-toolchain.rst > > +++ b/docs/misra/C-language-toolchain.rst > > @@ -531,6 +531,17 @@ A summary table of data types, sizes and > > alignment is below: > > - 64 bits > > - x86_64, ARMv8-A AArch64, RV64, PPC64 > > > > + * - xen_ulong_t > > + - 32 bits > > + - 32 bits > > + - x86_32 > > + > > + * - xen_ulong_t > > + - 64 bits > > + - 64 bits > > + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, ARMv8-R > > + AArch32, ARMv7-A > > > > > > We support neither ARMv8-R nor ARMv8-A Aarch32. > > > > I could possibly accept the latter because it works to. But the former is > > so far misleading. > > Yes I think you are right. Moreover this document > (C-language-toolchain.rst) is meant for the Xen build. While this patch > is trying to document the types used in the public headers for the > external-facing ABI. > > I'll move the information this patch is adding to a separate document, > specific to the public headers. I will only add the architectures > currently working: I'll add ARMv8-A Aarch32 because although it is > unsupported it is interesting to know the size of xen_ulong_t for > aarch32 in the public headers. I will remove ARMv8-R as it is not > available upstream. > > Thinking a bit more. What about Armv9? Rather than listing each version, > should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later?
Definitely you are right here but as for Armv8-R, Armv9 is not something that we explicitely support right now (even though it should work). Cheers Bertrand
