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

["Michael Kubacki" <michael.kubacki@outlook.com>]

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