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

["Laszlo Ersek" <lersek@redhat.com>]

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