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 55BA821AEB0A1 for ; Wed, 23 Aug 2017 02:01:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 721C5883B0; Wed, 23 Aug 2017 09:04:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 721C5883B0 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-43.phx2.redhat.com [10.3.116.43]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE6766B6E1; Wed, 23 Aug 2017 09:04:07 +0000 (UTC) To: Konrad Rzeszutek Wilk , anthony.perard@citrix.com, xen-devel@lists.xenproject.org, ian.jackson@citrix.com Cc: Jordan Justen , Leif Lindholm , Michael D Kinney , edk2-devel@lists.01.org, Andrew Fish , Ard Biesheuvel References: <20170816171731.19559-1-leif.lindholm@linaro.org> <150290697260.19421.6288312741594777109@jljusten-skl> <20170816192349.e5ubdgvsvjxjnbgs@bivouac.eciton.net> <150292303458.22617.12503389727996780425@jljusten-skl> <20170823013035.GA26686@localhost.localdomain> From: Laszlo Ersek Message-ID: <2a9604db-d19c-97de-3946-9b02092b93a3@redhat.com> Date: Wed, 23 Aug 2017 11:04:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170823013035.GA26686@localhost.localdomain> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 23 Aug 2017 09:04:10 +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, 23 Aug 2017 09:01:37 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hello Konrad, On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote: > 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). >> >> (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 > > Who did you email/speak to? I hadn't seen any emails sent by > you to xen-devel mailing list, but perhaps I missed them? These emails are not easy to find (even in my own mailbox) because my calls for help / suggestions for co-maintenance have been scattered over time, loosely tied to OVMF regressions on Xen, or new Xen features in OVMF. Keyword searches didn't help much, but I managed to find this email, for example: http://mid.mail-archive.com/f5e03398-33ca-c90d-743f-691d927657d3@redhat.com Anthony, Gary, and xen-devel were addressed (among others). On 09/08/16 12:24, I wrote: > Now, if you create a new platform (DSC + FDF) for Xen, that sort of > forces someone from the Xen community to assume co-maintainership for > the Xen bits. (Hopefully those bits would be easily identifiable by > pathname.) I'd welcome that *very much*. I remember more (for example I distinctly remember inviting Gary), but I can't locate that message now. On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote: > It should be fairly simple to expand the 0-day OSSTest to build > TianoCore and launch guests with it as a nice regression test. The point is to catch regressions before they are merged. This requires someone who uses Xen every day to review and/or test patches posted to edk2-devel that affect Xen code in OVMF. (If the OSSTest tool can identify and pick such patches from edk2-devel automatically, that would work too, of course.) Thanks, Laszlo