From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.8325.1601965260027730605 for ; Mon, 05 Oct 2020 23:21:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WSXKE1c/; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601965259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uui5fM/5SyeFwaudJZYARkzCz3PHFVopxbVJqzWPlQI=; b=WSXKE1c/a0CMY/0CfcKQYHQlN3HMFsl6UtdnxIvEPsCoqGh8wTRekqJk3AVqWnU1da5ot/ huDM+iHv4i2Iu9mTZ2yno//40k+oe3DkmXtXgPURjd1GMgrupmvq6b/DqAl9uENDvxqf5d iVnbX9Ad41oQp+3khGSkm8wg0e/Ect0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-199-Xb015EtOPfyRyxwy7H6zAw-1; Tue, 06 Oct 2020 02:20:55 -0400 X-MC-Unique: Xb015EtOPfyRyxwy7H6zAw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3C27680EF9C; Tue, 6 Oct 2020 06:20:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-235.ams2.redhat.com [10.36.112.235]) by smtp.corp.redhat.com (Postfix) with ESMTP id B76755C1BD; Tue, 6 Oct 2020 06:20:47 +0000 (UTC) Subject: Re: [edk2-platforms] [RFC] Compatibility Expectations in edk2-platforms To: Michael Kubacki , "devel@edk2.groups.io" Cc: Leif Lindholm , Ard Biesheuvel , Ray Ni , Sai Chaganty , Eric Dong , Dandan Bi , Michael D Kinney , Kelly Steele , Zailiang Sun , Yi Qian , Chasel Chiu , Nate DeSimone , Agyeman Prince , Bob Feng , Liming Gao , Abner Chang , Daniel Schaefer , Gilbert Chen References: From: "Laszlo Ersek" Message-ID: Date: Tue, 6 Oct 2020 08:20:46 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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