Re: [RFC] To port rv32 to Debian

[Helmut Grohne <helmut@subdivi.de>]

Hi Bo,

On Sat, May 20, 2023 at 10:15:04AM +0800, Bo YU wrote:
> Should to choose which ABI?
> ---------------------
> 
> Here I will listen to the opinions of various experts. In fact, what I
> understand is more or less from documents rather than the real needs
> of the industry. This time our bootstrap[0] is based on rv32gc, in
> fact, it should not be difficult to rebootstrap based on rv32imac or
> other ABI. It is impossible for us to meet the requirements of every
> vendor but we maybe need to determine ourself ABI early so I can send
> such patch to support riscv32 for gcc.

I think you know my opinion on this, but let me record it in public.

The only reason to use riscv32 is optimization by adapting to a very
specific board. It's a cost of development vs cost of production
trade-off that may be reasonable if producing large quantities of
devices. For everything else, just use riscv64 (or some other
architecture). The essence of such adaption is to *not* agree on what
riscv32 means. Different vendors want it to mean different things
depending on their application. As such, I think that a generic riscv32
architecture does not make sense at all.

On another level, building on 32bit architectures is known to be a dead
end due to address space exhaustion. If adding a 32bit architecture now,
it can only exist as an architecture that is driven by cross
compilation.

So yeah, I think riscv32 does make sense, but it makes very different
sense from how we usually think about architectures. For riscv32 to make
sense we have to:
 * Say goodbye to an ABI and explicitly allow riscv32 to mean different
   things at the same time.
 * Say goodbye to upgrading packages (and transitions in general).
 * Say goodbye to binary packages as an exchange format and only allow
   building OS images from source (like buildroot/ptxdist/yocto).

It's a very different kind of Debian distribution and not one that we
have now.

I don't think it makes sense to publish riscv32 binary packages and it
does not make sense either to build them natively on a riscv32 system
(even if operated using a riscv64 kernel).

Please consider this to be my personal view of things. I recognize that
others (and you) see things differently. Still, this bears quite some
similarity to what Aurelien and Jessica said.

Helmut