From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web11.6657.1602049354445849020 for ; Tue, 06 Oct 2020 22:42:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=VJ8xbTsQ; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 0975erJ9024568; Tue, 6 Oct 2020 22:42:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=4JjoNEzyKzXgzGEl1uLjND9AS0cqGVMGxqTeI4khlio=; b=VJ8xbTsQsfm7dvY1UJTc+ES6BjndHCCcYwIksVuewFocZjem5OOrHNF6/EeNQpZ129jg /Ocur0SgHLIMHoeeg+VIEFSJmNXgVIkI3nYOaLYdOIvM4jwuMnOY5gbyY8J2sgs9/w/U VoPIIK1zc9gtKVvm+L1zafxA0fjWyt96FjyIm5P1VNGQnX+njzQrxjokCZsRrbI1jlQb tIDyQSz1i0VIkEck+23sjLsGplqSN7zyn2pMQ2nprz8mG2FJ01rFc8y3y0b4Dc/DADAW JlxV6R2RRjgTn/4YLrQbHkDydNYx7vCAO1b4VYIj7m8N1FJn8HNxeKb7DFtr2s8HKF0D bw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp02.apple.com with ESMTP id 33xnvgmsr7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 06 Oct 2020 22:42:22 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHT00SROH6LDP80@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 06 Oct 2020 22:42:22 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QHT01100GPYHB00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 06 Oct 2020 22:42:21 -0700 (PDT) X-Va-A: X-Va-T-CD: 35bb29a019ebbb5591c2da17b19b903e X-Va-E-CD: 3b194878f2a9a2ea1355727676ba7348 X-Va-R-CD: 1790d97c3197cc087f1d971eff365e3c X-Va-CD: 0 X-Va-ID: 9747ea97-ce7e-4daa-84c5-a8172daf7401 X-V-A: X-V-T-CD: 35bb29a019ebbb5591c2da17b19b903e X-V-E-CD: 3b194878f2a9a2ea1355727676ba7348 X-V-R-CD: 1790d97c3197cc087f1d971eff365e3c X-V-CD: 0 X-V-ID: c8434813-5231-4a67-ab62-b4513a30293a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-07_04:2020-10-06,2020-10-07 signatures=0 Received: from [17.235.15.41] (unknown [17.235.15.41]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QHT00K0OH6DGZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 06 Oct 2020 22:42:15 -0700 (PDT) From: "Andrew Fish" Message-id: <4F0EFA84-7794-4E6A-BCEE-4BE925A20144@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms Date: Tue, 06 Oct 2020 22:42:13 -0700 In-reply-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" , Liming Gao , Abner Chang , Daniel Schaefer , Gilbert Chen , Christian Walter To: edk2-devel-groups-io , michael.kubacki@outlook.com References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-07_04:2020-10-06,2020-10-07 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_C09442B0-7734-4437-A071-DD95DA6CE6FA" --Apple-Mail=_C09442B0-7734-4437-A071-DD95DA6CE6FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 6, 2020, at 10:01 PM, Michael Kubacki wrote: >=20 > Hi Nate, >=20 > On 10/6/2020 9:19 PM, Desimone, Nathaniel L wrote: >> Hey Michael, >> On 10/5/20, 3:36 PM, Michael Kubacki wrot= e: >>>=20 >>> 1. Inconsistent maintainer support >>> * Some packages currently do not build. Some packages are not gett= ing >>> updated often. >>>=20 >>> * Example: Last week I had to update Vlv2TbltDevicePkg which did n= ot >>> build. >>> * Example: Many packages only document support for old toolchains. >> 100% agreed here. >>>=20 >>> 2. Inconsistent toolchain support >>>=20 >>> To build these according to instruction, a developer needs to install = Visual >>> 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 p= ort that Liming started some time ago. This would need to include robust su= pport for Windows, Linux, and Mac host systems. From what I remember the la= st status update was issues with stability of the LLVM linker's support for= PE/COFF output. >=20 > Aligning on Clang support would be great. It's worth noting that current= CI support in edk2 does not support Clang so that needs to be enabled - ht= tps://github.com/tianocore/edk2/blob/master/.pytool/Readme.md . >=20 Is adding a new toolchain just a documenting the config, and testing?=20 Thanks, Andrew Fish > Is anyone looking at those LLVM issues now? >=20 >> Otherwise build reproducibility will always be a problem since the bina= ry generated will be different depending on which OS/compiler the developer= was using at the time. The coreboot community handles this issue by only s= upporting GCC, which I think is inappropriate for TianoCore since Windows p= orts of GCC differ greatly from Linux versions. While I think the goal of s= upporting many different C toolchains is admirable and definitely appropria= te for edk2 core code... for edk2-platforms I think it would be better to h= ave everyone agree on a single cross-platform toolchain; at least for x86 a= nd ARM since clang supports those architectures well (maybe other architect= ures depending on the clang's maturity.) >>>=20 >>> 3. Inconsistent build requirements >>>=20 >>> Many builds use the "build" command. Others have script wrappers with >>> unique parameters. Platforms are free to choose what they do and do no= t >>> support and developers have to figure it out. >> We solved that for MinPlatform based boards with build_bios.py, but agr= eed 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 fo= r "build" to work everywhere, but I'm not sure what the status of that work= is. >=20 > 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 consist= ency at a repo level would be awesome. >=20 > Perhaps a community discussion around leveraging existing tool support f= or open source platforms would help with adoption. Apart from consistency a= cross open source platforms, usage could also serve as a practical example = to closed source consumers on how to better integrate such tools into their= environments. >=20 >>>=20 >>> 4. Lack of build health indicators >>>=20 >>> Basically, there is no public CI across platforms. It is not clear exa= ctly what >>> platform builds are broken, what configurations they are broken agains= t, >>> 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 hard= ware for automated testing of Open System Firmware, maybe we should check a= nd see if they would be interested in supporting automated testing for Tian= oCore. 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. >=20 > I look forward to hearing from 9elements. >=20 > Do you think it would be feasible for Intel to support something like Ka= bylakeOpenBoardPkg/GalagoPro3 and/or WhiskeylakeOpenBoardPkg/UpXtreme in pu= blic CI? >=20 >>> Without such support, I believe platforms can only have a dependency o= n >>> edk2 (not vice versa). Maintainers move their edk2 pointer when they h= ave >>> verified that their platform properly integrates the latest changes. T= his is >>> relatively common in relationships with package-based dependencies and >>> how this is typically handled outside edk2-platforms. I believe this i= s >>> reasonable even with public CI in place unless maintainers understand = and >>> 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 maintenance = is of boards over time. If a given board becomes stale, then the board beco= mes a candidate for getting deleted from master and moved to a legacy branc= h. 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_b= ranch 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 = well because as you note, the Bay Trail Minnow Max is not receiving particu= larly good maintenance at this point. A similar issue happened with PurleyO= penBoardPkg last year and you actually sent the patch series to delete it. >=20 > Deprecation branches sound reasonable to me personally. I'm not aware of= prior documentation or discussion around platform deprecation in edk2-plat= forms. Is anyone else? >=20 >>>=20 >>> 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-platfo= rms >>> integration and testing. >>>=20 >>> Thanks, >>> Michael >>>=20 >>>=20 >>>=20 >=20 >=20 >=20 --Apple-Mail=_C09442B0-7734-4437-A071-DD95DA6CE6FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 6,= 2020, at 10:01 PM, Michael Kubacki <michael.kubacki@outlook.com> wrote:

Hi Nate,<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">
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 do not build. Some packages are not getting
updated= often.

    * Example: Las= t week I had to update Vlv2TbltDevicePkg which did not
build.=
    * Example: Many packages only docume= nt support for old toolchains.
100% agreed here.=

2. Incon= sistent toolchain support

To build these accor= ding to instruction, a developer needs to install Visual
Stud= io dating back to 2015 (though it is 2020), and multiple versions of iASL,<= br class=3D"">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 support for Windows, Linux, and Mac host systems. From what= I remember the last status update was issues with stability of the LLVM li= nker's support for PE/COFF output.

Aligning on Clang support would be great. = It'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/Readme.md.


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

Thanks,

Andrew Fish

Is anyo= ne 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 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 d= iffer greatly from Linux versions. While I think the goal of supporting man= y different C toolchains is admirable and definitely appropriate for edk2 c= ore 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 supports those architectures well (maybe other architectures dependin= g 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 th= ey do and do not
support and developers have to figure it out= .
We solved that for MinPlatform based boards wi= th 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 extensibili= ty to BaseTools needed for "build" to work everywhere, but I'm not sure wha= t 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 p= artial to any particular solution as I've had positive experiences with bot= h but having more consistency at a repo level would be awesome.

Perhaps a community discussion around leveraging existing tool suppo= rt for open source platforms would help with adoption. Apart from consisten= cy across open source platforms, usage could also serve as a practical exam= ple to closed source consumers on how to better integrate such tools into t= heir environments.


4. Lack of build health indicators

Basically, there is no public CI across platforms. It is n= ot clear exactly what
platform builds are broken, what config= urations they are broken against,
how long they have been bro= ken, etc.
Public CI seems like a great idea. Pub= lic automated testing would also be awesome. I believe 9elements has been w= orking on building a pool of hardware for automated testing of Open System = Firmware, maybe we should check and see if they would be interested in supp= orting 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 su= pported in edk2-platforms.

I look forward to hearing from 9elements.
Do you think it would be feasible for Intel to support something li= ke 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 pointe= r when they have
verified that their platform properly integr= ates the latest changes. This is
relatively common in relatio= nships with package-based dependencies and
how this is typica= lly handled outside edk2-platforms. I believe this is
reasona= ble even with public CI in place unless maintainers understand and
accept the challenges and additional support that is involved with b= eing on
edk2/master.
Coreboot hand= les 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 f= or getting deleted from master and moved to a legacy branch. Sometimes enti= re technologies are dropped, for example FSP v1.0 is only supported up to c= oreboot 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 well b= ecause as you note, the Bay Trail Minnow Max is not receiving particularly = good maintenance at this point. A similar issue happened with PurleyOpenBoa= rdPkg last year and you actually sent the patch series to delete it.

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 chall= enges and see if
the community can align on some practices to= help simplify edk2-platforms
integration and testing.

Thanks,
Michael






--Apple-Mail=_C09442B0-7734-4437-A071-DD95DA6CE6FA--