> On Oct 2, 2019, at 11:14 AM, Abner Chang wrote: > > 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 > Thanks > Abner > >> -----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) > >> Cc: devel@edk2.groups.io ; Philippe Mathieu-Daudé > >> 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 > >