On Mon, Dec 27, 2021 at 10:29 AM Jessica Clarke <jrtc27@xxxxxxxxxx> wrote: > > On 27 Dec 2021, at 01:16, Guo Ren <guoren@xxxxxxxxxx> wrote: > > > > On Mon, Dec 27, 2021 at 4:31 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > >> On Sun, Dec 26, 2021 at 7:38 AM Guo Ren <guoren@xxxxxxxxxx> wrote: > >>> On Sun, Dec 26, 2021 at 4:36 PM Jisheng Zhang <jszhang3@xxxxxxxxxxxxxxxx> wrote: > >>>> On Wed, 22 Dec 2021 20:59:30 +0800 Guo Ren <guoren@xxxxxxxxxx> wrote: > >>>>> On Wed, Dec 22, 2021 at 2:10 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > >>>> > >>>> What about adding RV64 ILP32 support instead? This don't need HW side > >>>> modifications so can benefit all RV64. > >>> > >>> ILP32 is another topic in C Language Data Type Models and it couldn't > >>> replace the standard rv32 ecosystem. > >>> COMPAT is a common framework in Linux (7 arches have been supported), > >>> so let rv64 support COMPAT mode is considerable. > >>> > >>> Customers would choose ILP32 / RV32-compat by themself and that > >>> depends on which one has a better ecosystem. > >> > >> From a kernel perspective, supporting both is not much more work than > >> supporting either of them. We had the same debate for Arm64, and ended > >> up never merging the ILP32 patches despite them being well written > >> and maintainable, to limit the number of supported user space ABIs > >> as well as the possible attack vectors when there is an exploitable > >> bug that is specific to an ABI. > >> > >> arm64 does support big-endian mode, which is a similar niche, but it > >> can't easily be removed after it's already supported. Supporting normal > >> compat mode is the easiest here because it doesn't add another user > >> space ABI, but I'd strongly recommend not to add any other ones. > > > > @Palmer Dabbelt How do you think about supporting ILP32 & COMPAT both > > in rv64? And let users vote by foot which is better. > > As psABI TG co-chair I really do not want an ILP32 RV64 to exist if it > can at all be avoided. Every single attempt at an ILP32 ABI for a > 64-bit architecture has failed to take off in the past, so I struggle > to see why RV64 will be any different. So, in my opinion, there is a > relatively high barrier to entry for it to be an official frozen ABI, > and without it being that I doubt upstreams will want to go near it, be > it Linux, GCC, binutils or GCC, but they can speak for themselves if > they feel otherwise. > > Also, with every year that goes by, ILP32 becomes more and more limited > in what you can use it for, due to increased memory footprints... Agree, I think we are on the right road :) > > Jess > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
