From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E9DB32095B9ED for ; Thu, 17 Aug 2017 03:09:51 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id z91so29893452wrc.4 for ; Thu, 17 Aug 2017 03:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=T2Qza39Y6Z7CPjyKRliM+QnTa4TNsecBwykybIGg3Lo=; b=AuU1+ec/6nluE/qO0HfFMwWpJhzgtdz32bH/2yfbH6g3TkJmotriH1PYbRaxoAgqxL AVg4y+xQHcn+ak++Qe/txjhhJXlxz/1xP1CBdZssuNdEH/mHI7aG/Iiqx9Vv1GPOigvE tb7o8lOORcIH5wG4/qqJRYMdlrNTYRoppUYeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=T2Qza39Y6Z7CPjyKRliM+QnTa4TNsecBwykybIGg3Lo=; b=Fynmo8nUP34ROioraD77JX7xiNBIYB2bkKlNrFKDYpcndQL357WlVjvfxDS1tz0urd Gsrn8hpY29zJHGhR8j/piXYf+viqWN5rcXNV1mCrYB4xVYUgGgxIb4oyoc+fOfltfxqS 88H6mILvQe1VsxtMwo4fcgfhYzu/4XGyUJWN1vLHfIdQs54fZvb3fN+723DZd/4RUFyG aTuWSsvrgMxri1GCJNIwt6///baCEk16TNvIm8CIsMs1hGjKdmJsmcWky4G2UQegIYeO 9FYiZhj0J9MkZqVH3Rx57FXqOolbBjcI/TnQjEzmuFMFX1wJ6S02bTF6A3ef2fBgaZkQ 9i7Q== X-Gm-Message-State: AHYfb5h2wzBImejDNc4GTa0/hLx+rCgHcPev3KbBm4vnHND6bGwkFa8d Zef/rEqFNW106VJd X-Received: by 10.28.187.86 with SMTP id l83mr906806wmf.162.1502964737453; Thu, 17 Aug 2017 03:12:17 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id 94sm2514390wrb.55.2017.08.17.03.12.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Aug 2017 03:12:16 -0700 (PDT) Date: Thu, 17 Aug 2017 11:12:14 +0100 From: Leif Lindholm To: Laszlo Ersek Cc: Jordan Justen , edk2-devel@lists.01.org, Ard Biesheuvel , Andrew Fish , Michael D Kinney , Steve.Capper@arm.com Message-ID: <20170817101214.abtzjjngs2gxn3r6@bivouac.eciton.net> References: <20170816171731.19559-1-leif.lindholm@linaro.org> <150290697260.19421.6288312741594777109@jljusten-skl> <20170816192349.e5ubdgvsvjxjnbgs@bivouac.eciton.net> <150292303458.22617.12503389727996780425@jljusten-skl> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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: Thu, 17 Aug 2017 10:09:52 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote: > 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). Well, I'm the one who keeps pushing for it, so it'd be impolite of me to suggest that someone else should have to deal with it. > (2) Sharing more code between modules that aren't inherently > architecture-independent (and virtualization platform-independent) is risky. Let me start by clarifying what I would like to see: - ArmVirtPkg and OvmfPkg merged into one package. - Merging a lot of common items into shared .dsc.inc and .fdf.inc across all platforms. - ARM/AARCH64 platforms added to build.sh/create-release.py. - End. > 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). All of the above, I consider a lot less important to deal with short (or even medium) term. Where and when things make sense to break out, I'm sure you will do so without prompting. What I want to do is remove the current structural barrier we have. > 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). Let's be honest here. Yes, there is a risk of 32-bit ARM and RISC-V ending up poorly tested. That is also much less of an issue than ARM64 and X64. If that changes, absolutely, validation for those needs to be seriously improved. But frankly, at this stage, _not_ setting up some CI jobs running LuvOS on all QEMU/TCG targets on a nightly basis is just down to laziness. (That finger is pointing very strongly towards myself.) QEMU/KVM would require a little bit more effort, but not tons. > 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.) Sure, but the Xen situation is completely different, since (as you say) there is no co-maintainer looking after that. This also means it would be completely valid to break out the Xen support into a separate package with S: Orphan. > 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. Sure. And I am not suggesting that the _code_ sharing needs to change at this point. I just feel there is more alignment between ArmVirtPkg/Qemu and OvmfPkg/Qemu than there is between OvmfPkg/Qemu and OvmfPkg/Xen (or indeed ArmVirtPkg/Qemu and ArmVirtPkg/Xen). > In fact, these stakes would be much better reflected if Ard *too* were a > Maintainer for OvmfPkg. I'm glad we agree :) / Leif