From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2B23B21CFA60E for ; Wed, 16 Aug 2017 16:45:36 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2C66B7972A; Wed, 16 Aug 2017 23:48:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2C66B7972A Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-59.phx2.redhat.com [10.3.116.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id AAB825D968; Wed, 16 Aug 2017 23:48:00 +0000 (UTC) To: Jordan Justen , Leif Lindholm Cc: edk2-devel@lists.01.org, Ard Biesheuvel , Andrew Fish , Michael D Kinney References: <20170816171731.19559-1-leif.lindholm@linaro.org> <150290697260.19421.6288312741594777109@jljusten-skl> <20170816192349.e5ubdgvsvjxjnbgs@bivouac.eciton.net> <150292303458.22617.12503389727996780425@jljusten-skl> From: Laszlo Ersek Message-ID: Date: Thu, 17 Aug 2017 01:47:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150292303458.22617.12503389727996780425@jljusten-skl> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 16 Aug 2017 23:48:02 +0000 (UTC) Subject: Re: [PATCH] Maintainers.txt: update OvmfPkg maintainership X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:45:36 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/17/17 00:37, Jordan Justen wrote: > On 2017-08-16 12:23:49, Leif Lindholm wrote: [snip] >> - the value proposition >> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg >> simplifies the task of maintaining feature parity between the two. >> (It is no secret that I would love to see them as a single package, >> making it easier to clean up the way EDK2-for-qemu gets packaged by >> Linux distributions.) > > I would also prefer to have OVMF support ARM and eventually RISC-V as > well. I don't think Laszlo feels as confident about this though. I have two concerns: (1) Reorganizing OvmfPkg for this would take an immense amount of time (with possible regressions). (2) Sharing more code between modules that aren't inherently architecture-independent (and virtualization platform-independent) is risky. By "sharing more code", I mean extracting further library classes and then unifying originally separate drivers. I also mean extracting common files from separate library instances, and then unifying the lib instances in a common directory, with multiple INF files, or with arch-dependent sections in the one resultant INF file. Another method is to control the same set of drivers / library instances differently, via dynamic PCDs. While all this is great for code de-duplication, the chance of regressions skyrockets if the code de-dup is not matched by a similar overlap in maintenance (that is, review and testing). Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any kind of Xen. I've never seen RISC-V hardware (and probably won't -- nested TCG with QEMU doesn't count). The best counter-indication for this kind of increased sharing is the *numerous* Xen-related regressions that have slipped through in the past, simply because none of the OvmfPkg maintainers use Xen. (And the Xen project seems to be unwilling or unable to delegate an official reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite my repeated requests.) This has happened under ArmVirtPkg too (I recall ACPI vs. DT related changes -- surprisingly, even *that* selection is specific to the virtualization platform.) The bottleneck in open source development is not writing code, it is reviewing and regression-testing code. (This is painfully obvious in Linux kernel and QEMU development, but the same can be experienced on edk2-devel as well.) Therefore OvmfPkg's structure should match the distribution of OvmfPkg's active stake-holders over architectures and virtualization platforms. IMO the current code sharing between OvmfPkg and ArmVirtPkg, while certainly not 100% polished, is workable -- meaning that it mostly corresponds to the stakes that ArmVirtPkg and OvmfPkg maintainers and long-term contributors hold in the shared modules. In fact, these stakes would be much better reflected if Ard *too* were a Maintainer for OvmfPkg. Thanks Laszlo