Hi Helmut! On Sun, May 21, 2023 at 10:20:52AM +0200, Helmut Grohne wrote:
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.
Really. I still remember your view about riscv32 when I told you at thefirst time.:). But that was when I was just getting started with rebootstrap. When this
work is done, I understand your point more deeply.
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.
This inspired us to do something innovative for riscv32 including your"source-only architecture" proposal. But sometimes it depends on the specific needs of the vendor.
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.
Thanks for your understanding. I'm not sure if maintaining a rootfs with downstream is worthwhile but we will make some adjustments based on users
needs. For me personally, this is also an opportunity to learn how to bootstrap a new architecture from scratch and understand how Debian distributions work. Thanks again!
Helmut
-- Regards, -- Bo YU
Attachment:
signature.asc
Description: PGP signature