From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=J3JlxZMK; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by groups.io with SMTP; Wed, 02 Oct 2019 09:27:44 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x92GRIib017754; Wed, 2 Oct 2019 09:27:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UaSA/J+tLvIF3HoBpKoCqBtZQeHX5vTeQnrHoVS+4ks=; b=J3JlxZMKiwTYuFtQzE8snvinW0/eehgqV2mmkEjj2GW/0MRTEpaFohzwjjoSAFBEa84U PoqUdDGBVVZg6WXPg/65+cTHphbdqeXULvlSjQdujR7vPRvvUO1xEbH8Y1wchQJWyPSU rUCMtD045U6GTCUxppbHun1RK9tpwOJMC11/j2k7pFMw5Mwn9km9EFgxJrtRVJbcH57C qRkgQOBSPFkMyqKPce/yC7Z3sIcDcyN2jnOvBfqvyVfbmAtklFL955XZ7u1dnGeX0Lhk 17tRZwRbLLEQQHMRRiqb8EyZoL93XfbCN0mzkAQYX68P2EnqZtZw+FbrAW74kvGy+7As eA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2va6gwcq8b-21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 02 Oct 2019 09:27:42 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PYR00FGX9PIF2A0@ma1-mtap-s02.corp.apple.com>; Wed, 02 Oct 2019 09:27:19 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PYR006009N6EK00@nwk-mmpp-sz09.apple.com>; Wed, 02 Oct 2019 09:27:19 -0700 (PDT) X-Va-CD: 0 X-Va-ID: b0ad10eb-0f59-4e15-8b33-126fff61dea4 X-V-A: X-V-T-CD: 8efc8d540391cc00ea37267d401d25e4 X-V-E-CD: b7a16e2022cb1b6b896c302f4327cbde X-V-R-CD: 462fbdde6d10c7a78272aad1227aeadf X-V-CD: 0 X-V-ID: 0db2cb7a-6da1-4d07-8b61-4719f3131acd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-02_07:,, signatures=0 Received: from [17.103.11.227] (unknown [17.103.11.227]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PYR00FAI9PGL660@nwk-mmpp-sz09.apple.com>; Wed, 02 Oct 2019 09:27:17 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <22170513-D99D-43E1-8086-B322DAC50857@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v2 09/29] MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions. Date: Wed, 02 Oct 2019 11:27:16 -0500 In-reply-to: Cc: Leif Lindholm , =?utf-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Mike Kinney , Liming Gao To: devel@edk2.groups.io, abner.chang@hpe.com References: <1569198715-31552-1-git-send-email-abner.chang@hpe.com> <1569198715-31552-11-git-send-email-abner.chang@hpe.com> <20190926233928.GL25504@bivouac.eciton.net> <90c04adf-79b1-2d89-1683-c916444126c7@redhat.com> <20191001090705.GQ25504@bivouac.eciton.net> <20191002091317.GZ25504@bivouac.eciton.net> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-02_07:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_9DA49C32-BD66-4258-B8C3-CC478E34DC95" --Apple-Mail=_9DA49C32-BD66-4258-B8C3-CC478E34DC95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 2, 2019, at 11:14 AM, Abner Chang wrote: >=20 > Thanks Leif, let me check with maintainers. >=20 > 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] secti= on, instead I would like to use IoLibRiscV.c which conform with current sou= rce file organization under BaseIoLibIntrinsics. What's your preference? >=20 Abner, So is the plan to just copy IoLibArm.c to IoLibRiskV.c? I kind of agree wi= th 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 c= hange the file name of IoLibArm.c to IoLibNoIo.c and have ARM and RISC-V po= int at the common file? Thanks, Andrew Fish > Thanks > Abner >=20 >> -----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 Mathie= u-Daud=C3=A9 > >> Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v2 09/29] >> MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions. >>=20 >> 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. >>>>=20 >>>> IoLibArm, IoLibEbc and IoLibRiscV have *exactly* the same requirement= s. >>>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >> And one of those options does not pile up even more code duplication in= the >> tree. >>=20 >> But you are welcome to convince some other maintainer of the opposite. >>=20 >> / >> Leif >=20 >=20 --Apple-Mail=_9DA49C32-BD66-4258-B8C3-CC478E34DC95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 2, 20= 19, at 11:14 AM, Abner Chang <abner.chang@hpe.com> wrote:

Thanks Leif, let me check with maintain= ers.

Hi Mike and Liming,
How do you think about to use IoLibArm as the I/O lib ins= tance 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 w= ith current source file organization under BaseIoLibIntrinsics. What's your= preference?


Abn= er,

So is the plan to just copy IoLibAr= m.c to IoLibRiskV.c? I kind of agree with Leif that having two copies of th= e same thing does not make sense. I do see your point about naming, but may= be the issue the IoLibArm.c name. I don't see anything ARM specific in &nbs= p;IoLibArm.c it seems to me it is generic C code for a platform that does n= ot 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,

An= drew Fish

Thanks
A= bner

-----Original Message-----
= From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Wednesday, Octobe= r 2, 2019 5:13 PM
To: Chang, Abner (HPS SW/FW Technologist) &= lt;abner.chang@hpe.com>
Cc: <= a href=3D"mailto:devel@edk2.groups.io" class=3D"">devel@edk2.groups.io;= Philippe Mathieu-Daud=C3=A9 <philmd@redhat.com>
Subject: Re: [edk2-devel] [e= dk2-staging/RISC-V-V2 PATCH v2 09/29]
MdePkg/BaseIoLibIntrins= ic: RISC-V I/O intrinsic functions.

On Wed, Oc= t 02, 2019 at 01:30:12AM +0000, Chang, Abner (HPS SW/FW
Techn= ologist) wrote:
There should be exactly one variant of IoLib.c= . Well, these days we
need a separate one for ARM/AARCH64 und= er hw virtualization.

IoLibArm, IoLibEbc and I= oLibRiscV have *exactly* the same requirements.
And now x86 u= ses 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 ar= chitecture's"
code than it is to add another file doing exact= ly the same thing but
pretending it is "for" another architec= ture.

And one of those options does not pile u= p even more code duplication in the
tree.

But you are welcome to convince some other maintainer of the oppo= site.

/
   Leif


--Apple-Mail=_9DA49C32-BD66-4258-B8C3-CC478E34DC95--