From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by mx.groups.io with SMTP id smtpd.web10.2841.1602556180616401757 for ; Mon, 12 Oct 2020 19:29:42 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: byosoft.com.cn, ip: 58.240.74.242, mailfrom: gaoliming@byosoft.com.cn) Received: from DESKTOPS6D0PVI ([58.246.60.130]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Tue, 13 Oct 2020 10:29:02 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: , , Cc: "'Desimone, Nathaniel L'" , "'Leif Lindholm'" , "'Laszlo Ersek'" , "'Ard Biesheuvel'" , "'Ni, Ray'" , "'Chaganty, Rangasai V'" , "'Dong, Eric'" , "'Bi, Dandan'" , "'Mike Kinney'" , "'Steele, Kelly'" , "'Sun, Zailiang'" , "'Qian, Yi'" , "'Chiu, Chasel'" , "'Agyeman, Prince'" , "'Feng, Bob C'" , "'Abner Chang'" , "'Daniel Schaefer'" , "'Gilbert Chen'" , "'Christian Walter'" References: <4F0EFA84-7794-4E6A-BCEE-4BE925A20144@apple.com> In-Reply-To: <4F0EFA84-7794-4E6A-BCEE-4BE925A20144@apple.com> Subject: =?UTF-8?B?5Zue5aSNOiBbZWRrMi1kZXZlbF0gW2VkazItcGxhdGZvcm1zXSBbUkZDXSBDb21wYXRpYmlsaXR5IEV4cGVjdGF0aW9ucyBpbiBlZGsyLXBsYXRmb3Jtcw==?= Date: Tue, 13 Oct 2020 10:29:03 +0800 Message-ID: <005b01d6a108$9e4635a0$dad2a0e0$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHR1GqWb1zJKYXWsEwzMWUvZOrFggF4Hk2wA0W0Ja8CJIVFR6lnVELA Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D6A14B.AC6AAE20" Content-Language: zh-cn ------=_NextPart_000_005C_01D6A14B.AC6AAE20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable CLANG tool issue has been resolved. CLANGPDB tool chain has been added in Edk2. OVMF IA32X64 platform has been verified on Windows/Linux/Mac with CLANGPDB tool chain. On release build, OVMF IA32X64 can generates the same binary BIOS images on Windows/Linux/Mac OS.=20 =20 Here is wiki page https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain.= =20 =20 Thanks Liming =B7=A2=BC=FE=C8=CB: bounce+27952+65963+4905953+8761045@groups.io =B4=FA=B1=ED Andrew Fish vi= a groups.io =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C27=C8=D5 13:42 =CA=D5=BC=FE=C8=CB: edk2-devel-groups-io ; michael.kubacki@outlook.com =B3=AD=CB=CD: Desimone, Nathaniel L ; Leif= Lindholm ; Laszlo Ersek ; Ard Biesheuvel ; Ni, Ray ; Chaganty, Rangasai V ; Dong, Eric ; Bi, Dandan ; Mike Kinney ; Steele, Kelly ; Sun, Zailiang ; Qian, Yi ; Chiu, Chasel ; Agyeman, Prince ; Feng, Bob C ; Liming Gao ; Abner Chang ; Daniel Schaefer ; Gilbert Chen ; Christian Walter =D6=F7=CC=E2: Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expect= ations in edk2-platforms =20 =20 On Oct 6, 2020, at 10:01 PM, Michael Kubacki > wrote: =20 Hi Nate, On 10/6/2020 9:19 PM, Desimone, Nathaniel L wrote: Hey Michael, On 10/5/20, 3:36 PM, Michael Kubacki > wrote: 1. Inconsistent maintainer support * Some packages currently do not build. Some packages are not getting updated often. * Example: Last week I had to update Vlv2TbltDevicePkg which did not build. * Example: Many packages only document support for old toolchains. 100% agreed here. 2. Inconsistent toolchain support To build these according to instruction, a developer needs to install Visu= al Studio dating back to 2015 (though it is 2020), and multiple versions of iASL, NASM, a separate host OS for Linux/Windows builds, etc. IMHO, the best way forward would be to finish the EDK II native clang port that Liming started some time ago. This would need to include robust suppo= rt for Windows, Linux, and Mac host systems. From what I remember the last status update was issues with stability of the LLVM linker's support for PE/COFF output. Aligning on Clang support would be great. It's worth noting that current C= I support in edk2 does not support Clang so that needs to be enabled - https://github.com/tianocore/edk2/blob/master/.pytool/Readme.md. =20 Is adding a new toolchain just a documenting the config, and testing?=20 =20 Thanks, =20 Andrew Fish Is anyone looking at those LLVM issues now? Otherwise build reproducibility will always be a problem since the binary generated will be different depending on which OS/compiler the developer w= as using at the time. The coreboot community handles this issue by only supporting GCC, which I think is inappropriate for TianoCore since Windows ports of GCC differ greatly from Linux versions. While I think the goal of supporting many different C toolchains is admirable and definitely appropriate for edk2 core code... for edk2-platforms I think it would be better to have everyone agree on a single cross-platform toolchain; at lea= st for x86 and ARM since clang supports those architectures well (maybe other architectures depending on the clang's maturity.) 3. Inconsistent build requirements Many builds use the "build" command. Others have script wrappers with unique parameters. Platforms are free to choose what they do and do not support and developers have to figure it out. We solved that for MinPlatform based boards with build_bios.py, but agreed that that at an overall project level this is still an issue. I believe Bo= b and Liming were working on adding extensibility to BaseTools needed for "build" to work everywhere, but I'm not sure what the status of that work is. I've always liked the simplicity of build_bios.py. There's also a lot of effort put into edk2-pytool-extensions. I'm not partial to any particular solution as I've had positive experiences with both but having more consistency at a repo level would be awesome. Perhaps a community discussion around leveraging existing tool support for open source platforms would help with adoption. Apart from consistency across open source platforms, usage could also serve as a practical exampl= e to closed source consumers on how to better integrate such tools into thei= r environments. 4. Lack of build health indicators Basically, there is no public CI across platforms. It is not clear exactly what platform builds are broken, what configurations they are broken against, how long they have been broken, etc. Public CI seems like a great idea. Public automated testing would also be awesome. I believe 9elements has been working on building a pool of hardwa= re for automated testing of Open System Firmware, maybe we should check and s= ee if they would be interested in supporting automated testing for TianoCore. We would also need to see what the intersection is between what they have = in their pool and what boards are supported in edk2-platforms. I look forward to hearing from 9elements. Do you think it would be feasible for Intel to support something like KabylakeOpenBoardPkg/GalagoPro3 and/or WhiskeylakeOpenBoardPkg/UpXtreme in public CI? Without such support, I believe platforms can only have a dependency on edk2 (not vice versa). Maintainers move their edk2 pointer when they have verified that their platform properly integrates the latest changes. This = is relatively common in relationships with package-based dependencies and how this is typically handled outside edk2-platforms. I believe this is reasonable even with public CI in place unless maintainers understand and accept the challenges and additional support that is involved with being o= n edk2/master. Coreboot handles this problem by auditing the how good the maintenance is = of boards over time. If a given board becomes stale, then the board becomes a candidate for getting deleted from master and moved to a legacy branch. Sometimes entire technologies are dropped, for example FSP v1.0 is only supported up to coreboot 4.11, for that reason there is a long-lived 4.11_branch in coreboot git to maintain platforms dependent on FSP v1.0 binaries. I think we need some sort of deprecation process for edk2-platforms as wel= l because as you note, the Bay Trail Minnow Max is not receiving particularl= y good maintenance at this point. A similar issue happened with PurleyOpenBoardPkg last year and you actually sent the patch series to delete it. Deprecation branches sound reasonable to me personally. I'm not aware of prior documentation or discussion around platform deprecation in edk2-platforms. Is anyone else? I just wanted to give my observation of some recent challenges and see if the community can align on some practices to help simplify edk2-platforms integration and testing. Thanks, Michael =20 ------=_NextPart_000_005C_01D6A14B.AC6AAE20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

CLANG tool issue has been resolved. CLANGPDB tool chain has = been added in Edk2. OVMF IA32X64 platform has bee= n verified on Windows/Linux/Mac with CLANGPDB tool chain. On release build,= OVMF IA32X64 can generates the same binary BIOS images on Windows/Linux/Ma= c OS. 

 

Here is wiki page https://github.com/tian= ocore/tianocore.github.io/wiki/CLANG9-Tools-Chain.

 

Thanks=

Liming

=B7=A2=BC= = =FE=C8=CB: bounce+27952+65963+4905953+8761045@groups.io &l= t;bounce+27952+65963+4905953+8761045@groups.io> =B4=FA=B1=ED Andrew Fish via groups.io
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C27=C8=D5 13= :42
=CA=D5=BC=FE=C8=CB: edk2-devel-groups-io <devel@edk2.groups.io>; michael.kubac= ki@outlook.com
=B3=AD=CB=CD: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>= ;; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.= com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Ni, Ray <ray.ni@= intel.com>; Chaganty, Rangasai V <rangasai.v.chaganty@intel.com>; = Dong, Eric <eric.dong@intel.com>; Bi, Dandan <dandan.bi@intel.com&= gt;; Mike Kinney <michael.d.kinney@intel.com>; Steele, Kelly <kell= y.steele@intel.com>; Sun, Zailiang <zailiang.sun@intel.com>; Qian,= Yi <yi.qian@intel.com>; Chiu, Chasel <chasel.chiu@intel.com>; = Agyeman, Prince <prince.agyeman@intel.com>; Feng, Bob C <bob.c.fen= g@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Abner Chang &= lt;abner.chang@hpe.com>; Daniel Schaefer <daniel.schaefer@hpe.com>= ; Gilbert Chen <gilbert.chen@hpe.com>; Christian Walter <christian= .walter@9elements.com>
=D6=F7=CC=E2: Re: [edk2-devel] [edk2-platforms] [RFC] Compatib= ility Expectations in edk2-platforms

 

 



On Oct 6, 2020, at 10:01 PM, Michael Kubacki <michael.kubacki@outlook.com>= ; wrote:

 

Hi Nate,
On 10/6/2020 9:19 PM, Desimone, Nathaniel L wrote:

Hey Michael,
On 10/5/20, 3:36 PM, Michael Kubacki <= ;michael.kubacki@outlook.com= > wrote:


1. Inconsisten= t maintainer support
    * Some packages currently d= o not build. Some packages are not getting
updated often.

 &= nbsp;  * Example: Last week I had to update Vlv2TbltDevicePkg whi= ch did not
build.
    * Example: Many packages on= ly document support for old toolchains.

<= p class=3DMsoNormal>100% agreed here.


2. Inconsistent toolchain support

To build these accordin= g to instruction, a developer needs to install Visual
Studio dating back= to 2015 (though it is 2020), and multiple versions of iASL,
NASM, a sep= arate host OS for Linux/Windows builds, etc.

IMHO, the best way forward would be to finish= the EDK II native clang port that Liming started some time ago. This would= need to include robust support for Windows, Linux, and Mac host systems. F= rom what I remember the last status update was issues with stability of the= LLVM linker's support for PE/COFF output.


Aligning on Clang support would be great. I= t's worth noting that current CI support in edk2 does not support Clang so = that needs to be enabled - = https://github.com/tianocore/edk2/blob/master/.pytool/Re= adme.md.

 

Is adding a new to= olchain just a documenting the config, and testing? =

 

Thanks,

 =

Andrew = Fish


Is anyone looking at those LLVM i= ssues now?


<= /span>

Otherwise build re= producibility will always be a problem since the binary generated will be d= ifferent depending on which OS/compiler the developer was using at the time= . The coreboot community handles this issue by only supporting GCC, which I= think is inappropriate for TianoCore since Windows ports of GCC differ gre= atly from Linux versions. While I think the goal of supporting many differe= nt C toolchains is admirable and definitely appropriate for edk2 core code.= .. for edk2-platforms I think it would be better to have everyone agree on = a single cross-platform toolchain; at least for x86 and ARM since clang sup= ports those architectures well (maybe other architectures depending on the = clang's maturity.)


3. Inconsiste= nt build requirements

Many builds use the "build" command.= Others have script wrappers with
unique parameters. Platforms are free = to choose what they do and do not
support and developers have to figure = it out.

We s= olved that for MinPlatform based boards with build_bios.py, but agreed that= that at an overall project level this is still an issue. I believe Bob and= Liming were working on adding extensibility to BaseTools needed for "= build" to work everywhere, but I'm not sure what the status of that wo= rk is.


I've= always liked the simplicity of build_bios.py. There's also a lot of effort= put into edk2-pytool-extensions. I'm not partial to any particular solutio= n as I've had positive experiences with both but having more consistency at= a repo level would be awesome.

Perhaps a community discussion aroun= d leveraging existing tool support for open source platforms would help wit= h adoption. Apart from consistency across open source platforms, usage coul= d also serve as a practical example to closed source consumers on how to be= tter integrate such tools into their environments.



4. Lack of build health indicators

Basically, there is no = public CI across platforms. It is not clear exactly what
platform builds= are broken, what configurations they are broken against,
how long they = have been broken, etc.

Public CI seems like a great idea. Public automated testing would a= lso be awesome. I believe 9elements has been working on building a pool of = hardware for automated testing of Open System Firmware, maybe we should che= ck and see if they would be interested in supporting automated testing for = TianoCore. We would also need to see what the intersection is between what = they have in their pool and what boards are supported in edk2-platforms.


I look forwar= d to hearing from 9elements.

Do you think it would be feasible for I= ntel to support something like KabylakeOpenBoardPkg/GalagoPro3 and/or Whisk= eylakeOpenBoardPkg/UpXtreme in public CI?


<= /p>

Wit= hout such support, I believe platforms can only have a dependency on
edk= 2 (not vice versa). Maintainers move their edk2 pointer when they have
v= erified that their platform properly integrates the latest changes. This is=
relatively common in relationships with package-based dependencies and<= br>how this is typically handled outside edk2-platforms. I believe this is<= br>reasonable even with public CI in place unless maintainers understand an= d
accept the challenges and additional support that is involved with bei= ng on
edk2/master.

Coreboot handles this problem by auditing the how good the maintenan= ce is of boards over time. If a given board becomes stale, then the board b= ecomes a candidate for getting deleted from master and moved to a legacy br= anch. Sometimes entire technologies are dropped, for example FSP v1.0 is on= ly supported up to coreboot 4.11, for that reason there is a long-lived 4.1= 1_branch in coreboot git to maintain platforms dependent on FSP v1.0 binari= es.
I think we need some sort of deprecation process for edk2-platforms = as well because as you note, the Bay Trail Minnow Max is not receiving part= icularly good maintenance at this point. A similar issue happened with Purl= eyOpenBoardPkg last year and you actually sent the patch series to delete i= t.


Deprecat= ion branches sound reasonable to me personally. I'm not aware of prior docu= mentation or discussion around platform deprecation in edk2-platforms. Is a= nyone else?


=

I just wanted to give my observation of some recent challenges and see if=
the community can align on some practices to help simplify edk2-platfor= ms
integration and testing.

Thanks,
Michael





 

------=_NextPart_000_005C_01D6A14B.AC6AAE20--