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

Re: Packaging of the RISC-V ecosystem?



I've led the packaging of Fedora on RISC-V
(https://fedoraproject.org/wiki/Architectures/RISC-V).  As of this
moment we have packaged 12939 source packages / 25769 binary
packages[*], which is about 2/3rds of Fedora.

If you have a problem with any package in Debian, then please take a
look at the corresponding SRPM
(https://fedorapeople.org/groups/risc-v/SRPMS/) to give you a clue
about what we did.  You can do:

  rpm2cpio foo.src.rpm | cpio -id

to unpack the sources.

I was interested to read this thread because I would very much like to
avoid either of (1) Debian using a different architecture name or
(2) an explosion of "riscv64abcdef" as we have on (for example) mips.

As a policy Fedora is targetting RV64G little endian as a minimum
platform.  We are not _yet_ building any multiarch (32 bit) packages,
because Fedora is a server- and desktop-focussed distribution, and
32-bit is essentially irrelevant there, but we might build a 32 bit
cross-compiler in future to support Minion Cores.  We are not
considering big endian at all.  Little endian won (unfortunately, but
that's the reality), and I've never heard of any RISC-V hardware using
anything other than LE.

No trademark problems have ever been raised by anyone over using
"riscv64" in a non-disparaging way (but IANAL).

The kernel returns "riscv64" (or "riscv32" or "riscv128") because we
are using this patch which I believe is upstream now or going upstream:

  https://github.com/rwmjones/fedora-riscv/blob/master/stage3-kernel/0001-riscv64_makefile.patch

I would like to deal with other extensions (beyond G) by using a
/proc/cpuinfo or CPUID-type mechanism (unfortunately riscv-linux is
lacking in this area, but it's an obvious omission).  By using this +
ifunc etc we can avoid needing either different architecture strings
to describe extensions -- very invasive -- or requiring multiple
rounds of compilation.

In particular I think using "rv64g" is a terrible idea because there
are going to be lots of extensions to this architecture in future, and
do you really want to have "rv64gc" "rv64gcabcdef" etc etc ad infinitum?

I've sent patches upstream to several key packages (systemd, elfutils,
strace, libaio, rpm etc) based on the assumptions above.

Rich.

[*] Note these numbers include noarch packages, but we have still
built thousands of RISC-V binaries.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/


Reply to: