Re: Packaging of the RISC-V ecosystem?
2016-11-09 23:59 Karsten Merker:
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.
I haven't followed that yet... it might be an issue as you say, but then
again RV64 is a codename in the specs and so on, wouldn't it have the
same problems? And wouldn't other arch names like "mips*" and "arm*"
and "amd*" be as problematic as any one that we might choose for the
RISC-V ports?
This might be similar to the APIs being copyrightable -- if the
adherence to standards are allowed by law, one has to explain somehow
that it is compatible with the spec, so it means using some RISC-V-y
terminology.
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.
I sympathise with the idea, in fact it is similar to what you proposed
with the dynamic loader pathname -- e.g. the name that gained more
traction was something like /lib/ld-linux-riscv64ifd_ilp32.so.1 and
/lib/ld-linux-riscv64ifd_lp64.so.1.
However, I have to say that having used "rv64" initially in the first
months, I came to like "riscv64" better.
So how about the following naming convention:
RV<optional "BE" big-endian identifier><WIDTH><LIST_OF_ISA_EXTENSIONS>
[...]
Examples for possible architecture names following this naming
convention could be: RV64G, RV32IMA, RVBE64G
If BE/LE is optional and G is optional as well (being the "default"), we
would have rv64 or riscv64, and then rv64imfac for example.
But in that case, if G is ommitted for being the default, it would not
serve as a good guide/example for future "flavours", with examples as
you mention (armhf in Debian and Raspbian).
I don't know yet which way I prefer...
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: