From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 2394321E2DA74 for ; Tue, 22 Aug 2017 18:28:09 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id p67so349877qkd.1 for ; Tue, 22 Aug 2017 18:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7OcgntKM9RpgIe8mVRptUnFiN6FLI64vi7VA+puHKQY=; b=uvaN77u/PGRV8owxj6oRdXh2OvFxDcoNTvD3JbAV/Wm5j7bTbrjYO/WjZr5kzTaU/j jUShJLtQh+kUwof8SeOngElkfvMmFuOpuUDg7aa00qc/te1BBzCMR7AAV4Y9xKbpV9iV mObf51Sw91Bs0TyrVDJHovmFKRTLMiDyZyc4MmWiEupZ5CbhvQ2Da2RoL5rXa1zmU2KG qww2CMqsXQKNqpKU8Ky9ymj84deWUkTGpH1RWZZhrpaNo0vypV4I4CZHNsEPo5a3VV6W vKxfMbsZpH/rYk5ZxiWHl52+JSIWppuwqt7tu64IQbt+20KP4X44/qxIM84jECaMK/iK gdqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=7OcgntKM9RpgIe8mVRptUnFiN6FLI64vi7VA+puHKQY=; b=sho4omCt3AL63SCA7J4nEX//uqYryf7oPM4cHCrn7KZvN2/l7Jwhw8p5tJXh8IkA3g Ee2K6Db8WehmJX84efSv0fEGrqsXTqfJViTefcFqXEMfNI6Ou78RHrT3CDq4BNomYjDR hrdk3lsDVJpCEc5GumrAEWb00f4WJq/O2/n5c6A0JshLC0x5mQ4VdJHtDY3kuNvsZflr G3fB86H4wX99cMXGCv52o6UIscoQQRB4LYEuPSZCgR0Unl9TFuebjR/45JGj/ciXwNpE Jxn0DCa0O5Y98O038AZFdHFwcgFN7ac9rKeuEYYAoRZD7v7uaeUdFLszY/MkC8U/VN6W wt7g== X-Gm-Message-State: AHYfb5ifsqt/JWrj/RYU4xH69O1A1aE3XeWgWR9SlD0eLdxm8NCCOgHv v9pO7bTE/VmTmQ== X-Received: by 10.55.36.20 with SMTP id w20mr1532939qkg.318.1503451841312; Tue, 22 Aug 2017 18:30:41 -0700 (PDT) Received: from localhost.localdomain (209-6-200-48.s4398.c3-0.smr-ubr2.sbo-smr.ma.cable.rcncustomer.com. [209.6.200.48]) by smtp.gmail.com with ESMTPSA id f184sm230270qkd.57.2017.08.22.18.30.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 Aug 2017 18:30:40 -0700 (PDT) Sender: Konrad Rzeszutek Date: Tue, 22 Aug 2017 21:30:37 -0400 From: Konrad Rzeszutek Wilk To: Laszlo Ersek , 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 Message-ID: <20170823013035.GA26686@localhost.localdomain> 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: Mutt/1.8.3 (2017-05-23) 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 01:28:09 -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). > > (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? It should be fairly simple to expand the 0-day OSSTest to build TianoCore and launch guests with it as a nice regression test. > 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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel