[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] To port rv32 to Debian

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 the
first 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

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!


  Bo YU

Attachment: signature.asc
Description: PGP signature

Reply to: