[edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Michael Kubacki]

Hi all,

First, I'd like to clarify that I completely support the development of 
open source edk2 platforms and this observation is only intended to 
suggest an improvement for interoperability with edk2 development and 
not to detract from the great work happening in open source platforms.

There's currently an expectation that edk2-platforms must build with 
edk2/master. I'd like to address the present lack of infrastructure and 
uniformity in edk2-platforms that, in my opinion, makes this perpetually 
painful.

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.

2. Inconsistent toolchain support

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.

Just a few quick examples:

    * Vlv2TbltDevicePkg documented supported toolchains:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/Vlv2TbltDevicePkg/Readme.md

      * Compilers: VS13, VS15
      * Windows DDK: 3790.1830 in C:\WINDDK\3790.1830
      * Python: 3
      * iASL: iasl-win-20160527 in C:\ASL
      * NASM: 2.12.02 in C:\NASM
      * OpenSSL: Latest version in C:\Openssl (add OPENSSL_PATH)

   * Platform/ARM supported toolchains:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md

      * OS: A 32-bit or 64-bit Linux host machine.
      * Compilers: Visual Studio is not officially supported, 
experimental support can be found here: 
[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs]

   * Platform/Intel (MinPlatformPkg):
     * Compilers: VS15
     * Python: 3.7.3
     * iASL compiler: latest in C:\ASL
     * NASM: latest in C:\NASM

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.

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.

6. Lack of community testing capability

An edk2 contributor cannot be expected to understand the nuances of 
every platform in edk2-platforms to always make the right integration 
decision for a change in edk2. Platform objectives like performance and 
security vary and are not clearly documented. In turn, this slows 
progress in edk2. In many cases, edk2 contributors do not have a way to 
check for runtime regressions in edk2-platforms as they do not possess 
the platform they're requested to update.


Within the purview of an individual edk2-platforms maintainer, these 
problems are relatively insignificant, largely due to the somewhat 
isolated nature of platform development. However, it does not scale well 
to edk2 contributors that need to build and test N platforms.

While community alignment on build tools, toolchain support, keeping 
current, and other areas would help, I believe many of the concerns can 
be mitigated with publicly accessible CI that proves current build 
support, build health, build commands, allows developer build testing, 
and potentially even device boot regression testing for those without 
platforms on hand.

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 on edk2/master.

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

Re: [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Laszlo Ersek]

On 10/06/20 00:36, Michael Kubacki wrote:
> Hi all,
> 
> First, I'd like to clarify that I completely support the development of
> open source edk2 platforms and this observation is only intended to
> suggest an improvement for interoperability with edk2 development and
> not to detract from the great work happening in open source platforms.
> 
> There's currently an expectation that edk2-platforms must build with
> edk2/master. I'd like to address the present lack of infrastructure and
> uniformity in edk2-platforms that, in my opinion, makes this perpetually
> painful.
> 
> 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.
> 
> 2. Inconsistent toolchain support
> 
> 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.
> 
> Just a few quick examples:
> 
>    * Vlv2TbltDevicePkg documented supported toolchains:
> 
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/Vlv2TbltDevicePkg/Readme.md
> 
> 
>      * Compilers: VS13, VS15
>      * Windows DDK: 3790.1830 in C:\WINDDK\3790.1830
>      * Python: 3
>      * iASL: iasl-win-20160527 in C:\ASL
>      * NASM: 2.12.02 in C:\NASM
>      * OpenSSL: Latest version in C:\Openssl (add OPENSSL_PATH)
> 
>   * Platform/ARM supported toolchains:
> 
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md
> 
> 
>      * OS: A 32-bit or 64-bit Linux host machine.
>      * Compilers: Visual Studio is not officially supported,
> experimental support can be found here:
> [https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs]
> 
>   * Platform/Intel (MinPlatformPkg):
>     * Compilers: VS15
>     * Python: 3.7.3
>     * iASL compiler: latest in C:\ASL
>     * NASM: latest in C:\NASM
> 
> 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.
> 
> 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.
> 
> 6. Lack of community testing capability
> 
> An edk2 contributor cannot be expected to understand the nuances of
> every platform in edk2-platforms to always make the right integration
> decision for a change in edk2. Platform objectives like performance and
> security vary and are not clearly documented. In turn, this slows
> progress in edk2. In many cases, edk2 contributors do not have a way to
> check for runtime regressions in edk2-platforms as they do not possess
> the platform they're requested to update.
> 
> 
> Within the purview of an individual edk2-platforms maintainer, these
> problems are relatively insignificant, largely due to the somewhat
> isolated nature of platform development. However, it does not scale well
> to edk2 contributors that need to build and test N platforms.
> 
> While community alignment on build tools, toolchain support, keeping
> current, and other areas would help, I believe many of the concerns can
> be mitigated with publicly accessible CI that proves current build
> support, build health, build commands, allows developer build testing,
> and potentially even device boot regression testing for those without
> platforms on hand.
> 
> 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 on edk2/master.
> 
> 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.

Yes, a builder CI would be nice.

Thanks,
Laszlo

Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Nate DeSimone]

Hey Michael,

On 10/5/20, 3:36 PM, Michael Kubacki <michael.kubacki@outlook.com> 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 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 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 linker's support for PE/COFF output.

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 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 least 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 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 work is.

> 
> 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 hardware for automated testing of Open System Firmware, maybe we should check 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.

> 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 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 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 well because as you note, the Bay Trail Minnow Max is not receiving particularly good maintenance at this point. A similar issue happened with PurleyOpenBoardPkg last year and you actually sent the patch series to delete it.

> 
> 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
> 
> 
> 
> 

Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Michael Kubacki]

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. 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 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 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 linker'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 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 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 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 least 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 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 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 example to closed source consumers on how to better 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 also be awesome. I believe 9elements has been working 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 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 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 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 well because as you note, the Bay Trail Minnow Max is not receiving particularly 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
>>
>>
>> 
>>
> 

Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 6175 bytes --]



> 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. 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 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 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 linker'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 <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 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 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 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 least 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 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 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 example to closed source consumers on how to better 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 also be awesome. I believe 9elements has been working 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 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 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 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 well because as you note, the Bay Trail Minnow Max is not receiving particularly 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
>>> 
>>> 
>>> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 21818 bytes --]

回复: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[gaoliming]

[-- Attachment #1: Type: text/plain, Size: 7719 bytes --]

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. 

 

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

 

Thanks

Liming

发件人: bounce+27952+65963+4905953+8761045@groups.io
<bounce+27952+65963+4905953+8761045@groups.io> 代表 Andrew Fish via
groups.io
发送时间: 2020年10月7日 13:42
收件人: edk2-devel-groups-io <devel@edk2.groups.io>;
michael.kubacki@outlook.com
抄送: 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>; Mike Kinney <michael.d.kinney@intel.com>;
Steele, Kelly <kelly.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.feng@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Abner
Chang <abner.chang@hpe.com>; Daniel Schaefer <daniel.schaefer@hpe.com>;
Gilbert Chen <gilbert.chen@hpe.com>; Christian Walter
<christian.walter@9elements.com>
主题: Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in
edk2-platforms

 

 





On Oct 6, 2020, at 10:01 PM, Michael Kubacki <michael.kubacki@outlook.com
<mailto: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
<mailto:michael.kubacki@outlook.com> > 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 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 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 linker'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>
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 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 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 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 least
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 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 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 example
to closed source consumers on how to better 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 also be
awesome. I believe 9elements has been working 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 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 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 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 well
because as you note, the Bay Trail Minnow Max is not receiving particularly
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









 




[-- Attachment #2: Type: text/html, Size: 16988 bytes --]

Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

[Nate DeSimone]

[-- Attachment #1: Type: text/plain, Size: 9449 bytes --]

Liming,

That is awesome, thank you! My recommendation is moving all of our MinPlatform builds to this new toolchain then!

Thanks,
Nate

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Monday, October 12, 2020 7:29 PM
To: devel@edk2.groups.io; afish@apple.com; michael.kubacki@outlook.com
Cc: 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>; Kinney, Michael D <michael.d.kinney@intel.com>; Steele, Kelly <kelly.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.feng@intel.com>; 'Abner Chang' <abner.chang@hpe.com>; 'Daniel Schaefer' <daniel.schaefer@hpe.com>; 'Gilbert Chen' <gilbert.chen@hpe.com>; 'Christian Walter' <christian.walter@9elements.com>
Subject: 回复: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms

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.

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

Thanks
Liming
发件人: bounce+27952+65963+4905953+8761045@groups.io<mailto:bounce+27952+65963+4905953+8761045@groups.io> <bounce+27952+65963+4905953+8761045@groups.io<mailto:bounce+27952+65963+4905953+8761045@groups.io>> 代表 Andrew Fish via groups.io
发送时间: 2020年10月7日 13:42
收件人: edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; michael.kubacki@outlook.com<mailto:michael.kubacki@outlook.com>
抄送: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com<mailto:nathaniel.l.desimone@intel.com>>; Leif Lindholm <leif@nuviainc.com<mailto:leif@nuviainc.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Ard Biesheuvel <ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Chaganty, Rangasai V <rangasai.v.chaganty@intel.com<mailto:rangasai.v.chaganty@intel.com>>; Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>; Bi, Dandan <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Mike Kinney <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Steele, Kelly <kelly.steele@intel.com<mailto:kelly.steele@intel.com>>; Sun, Zailiang <zailiang.sun@intel.com<mailto:zailiang.sun@intel.com>>; Qian, Yi <yi.qian@intel.com<mailto:yi.qian@intel.com>>; Chiu, Chasel <chasel.chiu@intel.com<mailto:chasel.chiu@intel.com>>; Agyeman, Prince <prince.agyeman@intel.com<mailto:prince.agyeman@intel.com>>; Feng, Bob C <bob.c.feng@intel.com<mailto:bob.c.feng@intel.com>>; Liming Gao <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Abner Chang <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>; Daniel Schaefer <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Gilbert Chen <gilbert.chen@hpe.com<mailto:gilbert.chen@hpe.com>>; Christian Walter <christian.walter@9elements.com<mailto:christian.walter@9elements.com>>
主题: Re: [edk2-devel] [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms



On Oct 6, 2020, at 10:01 PM, Michael Kubacki <michael.kubacki@outlook.com<mailto: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<mailto:michael.kubacki@outlook.com>> 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 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 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 linker'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 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 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 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 least 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 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 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 example to closed source consumers on how to better 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 also be awesome. I believe 9elements has been working 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 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 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 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 well because as you note, the Bay Trail Minnow Max is not receiving particularly 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






[-- Attachment #2: Type: text/html, Size: 19660 bytes --]