Thanks Leif, let me check with maintainers.
Hi Mike and Liming,
How do you think about to use IoLibArm as the I/O lib instance for RISC-V arch? I personally don't like to use IoLibArm.c in [Source.RISCV64] section, instead I would like to use IoLibRiscV.c which conform with current source file organization under BaseIoLibIntrinsics. What's your preference?
Abner,
So is the plan to just copy IoLibArm.c to IoLibRiskV.c? I kind of agree with Leif that having two copies of the same thing does not make sense. I do see your point about naming, but maybe the issue the IoLibArm.c name. I don't see anything ARM specific in IoLibArm.c it seems to me it is generic C code for a platform that does not have IO Ports. So I guess we could just change the file name of IoLibArm.c to IoLibNoIo.c and have ARM and RISC-V point at the common file?
Thanks,
Andrew Fish
ThanksAbner-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Wednesday, October 2, 2019 5:13 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Cc: devel@edk2.groups.io; Philippe Mathieu-Daudé <philmd@redhat.com>
Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v2 09/29]
MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.
On Wed, Oct 02, 2019 at 01:30:12AM +0000, Chang, Abner (HPS SW/FW
Technologist) wrote:
There should be exactly one variant of IoLib.c. Well, these days we
need a separate one for ARM/AARCH64 under hw virtualization.
IoLibArm, IoLibEbc and IoLibRiscV have *exactly* the same requirements.
And now x86 uses NASM regardless of build platform, I think it would
make sense to move the contents of IoLibGcc and IoLibMsc into
assembler.
That looks weird and doesn't make sense to use Arm code for RISC-V
even the functionality is exactly the same to IoLibRiscV. I will still
keep it as IoLibRiscV.c until there is a generic IoLib for different
arch.
This is C code. It is no more weird to use "another architecture's"
code than it is to add another file doing exactly the same thing but
pretending it is "for" another architecture.
And one of those options does not pile up even more code duplication in the
tree.
But you are welcome to convince some other maintainer of the opposite.
/
Leif