Re: Packaging of the RISC-V ecosystem?
On Wed, Nov 09, 2016 at 10:46:24PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2016-11-09 19:43 Karsten Merker:
> >On Wed, Nov 09, 2016 at 09:55:25AM +0800, Paul Wise wrote:
> >
> >>I wonder how much of the RISC-V ecosystem we should include within Debian.
> >>
> >>Presumably we want a Linux riscv64el port and the associated
> >>bootloader, kernel and toolchain support.
>
> I was using just "riscv64" as port name, btw, since in principle nothing
> has been done for big-endian or heard about anybody interested in that.
>
> Other possibilities like rv64 would be shorter but less descriptive.
>
> I'm open to change it, but obviously if it's going to be something other
> than "riscv64" better to change it now.
Hello,
I had been thinking about the Debian architecture name a bit and
while riscv64 is the most obvious name for the "default" RISC-V
architecture, i.e. RV64G, it might be useful to actually specify
the full ISA variant in the architecture name to avoid situations
like on the Raspberry Pi with "armhf" meaning different things
based on context (armv7 with VFPv3 in Debian proper, armv6 with
VFPv2 in Raspbian).
For 64bit RISC-V systems, I suppose there will probably be no
actual hardware implementations that do not implement all of G
(i.e. IMAFD), but for 32bit systems I guess we will see all
possible combinations of ISA options from I-only to the full set
of IMAFD plus possibly a variety of other extentions. While
there probably won't be an official Debian port to most of those,
somebody might still want to provide a Debian build for some of
them similar to what happened with Raspbian and having a proper
naming convention defined in advance appears useful to me to
avoid multiarch issues.
>From a trademark point of view using something like rv64 instead
of riscv64 as the base part of the Debian architecture name would
(besides being shorter) avoid potential trademark issues. I am
not very happy with the RISC-V Foundation's proposed trademark
policy and would like to take precautions to avoid any potential
issues in that field.
So how about the following naming convention:
RV<optional "BE" big-endian identifier><WIDTH><LIST_OF_ISA_EXTENSIONS>
with
- WIDTH being the base register width, i.e. 32/64/128
- LIST_OF_ISA_EXTENSIONS being either
G for the full set of standard extensions (IMAFD)
or a list of the supported extensions in other cases.
I doubt that we will see big-endian RISC-V cores in practice as
the default endianess is little-endian, but the spec in theory
allows for BE-variants. Other architectures use an endianess
suffix at the end of the architecture name (mips64el, ppc64el),
but in the case of RISC-V that would cause problems with
differentiating it from the ISA extensions "B" and "E" and
appending the endianess identifier with an underscore might cause
problems with the Debian archive software, so placing it as an
optional infix seems to be the best solution to me.
Examples for possible architecture names following this naming
convention could be: RV64G, RV32IMA, RVBE64G
Comments welcome :-).
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: