From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by mx.groups.io with SMTP id smtpd.web12.10324.1583567589050765315 for ; Fri, 06 Mar 2020 23:53:09 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=r6k3ZlEd; spf=pass (domain: linaro.org, ip: 209.85.128.46, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f46.google.com with SMTP id f7so292181wml.4 for ; Fri, 06 Mar 2020 23:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPiExjg0b3CGJZHkdqrM1N2TD6RF0WJ04oRRK5jmYAQ=; b=r6k3ZlEdHMX8DyoFEVCAZf8fAegx/iB9TDob+q6CMqVX8IOPooYPfjRhvyf9gsFE/d OSREyZXNqGlxHwpk7Cd4Qs++YaQT2+0fxgViwy7Dd6j8AhkFPpVVn0f2y+owKolU9N5B b2Z2tEtMosuN03DSkJXLF0H8khvlMfh0lZsfLtfDkrQmUOid8WlCMZFZECy0Vn18mbDe sNU901Z0w7ic5ffformAWjEfoVFp4qERrt/HVWGB5qJvnFkuCOwgA4c0ipo7NY2VdVbi 0X+ubP15KwWXUjp/372GNyoNUzQlR6KiC3R8Qm8i9FfuUSIfuwnQFXVXL48AGe4+6Tcx zthw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPiExjg0b3CGJZHkdqrM1N2TD6RF0WJ04oRRK5jmYAQ=; b=rMdsPriQ7PmID7l/blKSHJtbbYjRCVBx2gssn0Cprasv7w84hjXCtOgINXDUZE0LiV NouRRst/krg6Cz4mL3OZQ2rdf7bxVRtsVQ8e89JLlWzA6Np2w966271MKCkfwphGCjEB pIh8yRa+A6uEv97I1llNxttgMTUUg2PqRaYkkgDoolcOKmuY3UonQg6xb4aswLJdrVXY WGwAHSF2VmKn0Cwe7B8IFt+E1vMI+686Sn9sk3fGWEveriJw02YBCBtDo4OPE2UwSPFe um6Yh/WQtq6LhibKpOpePwJH6dNcYyi6Ht0SpYHGrEBqt2u+IwWn2S5KuyXuUhuL5XdN zOKw== X-Gm-Message-State: ANhLgQ0vpFb3yezDBlSheMI3sofiedO0bg7ka61QQDUqxnhjP201BBmT I7RNaTN/aRw5PhTQsi5H2kZMY5p2GMO9hLG4W5gkSg== X-Google-Smtp-Source: ADFU+vvJXvsAOoJu1CQNIxWIbU8QK29SoxoA9DeRMakpHsZCvQQOt+aWtNLo7cFxcK9yTJI+m0mqCMKG4DAuRehIgCs= X-Received: by 2002:a7b:c354:: with SMTP id l20mr7486186wmj.40.1583567587440; Fri, 06 Mar 2020 23:53:07 -0800 (PST) MIME-Version: 1.0 References: <15F9E16A0219E7B7.19404@groups.io> <74D8A39837DF1E4DA445A8C0B3885C503F972D92@shsmsx102.ccr.corp.intel.com> In-Reply-To: From: "Ard Biesheuvel" Date: Sat, 7 Mar 2020 08:52:56 +0100 Message-ID: Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: Laszlo Ersek Cc: "Yao, Jiewen" , "devel@edk2.groups.io" , "rebecca@bsdio.com" , "Justen, Jordan L" Content-Type: text/plain; charset="UTF-8" On Sat, 7 Mar 2020 at 08:39, Laszlo Ersek wrote: > > Hi Jiewen, > > On 03/07/20 02:43, Yao, Jiewen wrote: > > Just saw Laszlo's email. Similar feedback. Especially, I like the regression test part. > > Thanks. > > > I am not sure how many virtual platforms we will have eventually. > > If there are more and more, maybe we can create a new edk2-virt-platform repo, and put them together there. (Similar to edk2-platform repo for the physical platform) > > Regarding the last part ("move them together here") -- I'm 100% opposed > to removing OvmfPkg and ArmVirtPkg from edk2. They *must* remain in the > exact same git repository where the core (MdePkg, MdeModulePkg, > CryptoPkg, SecurityPkg, UefiCpuPkg, ...) lives too, and share a common > git history. > Agreed. > ArmVirtPkg and OvmfPkg move very closely together with the core, most > significant ArmVirtPkg and OvmfPkg contributions need changes (and > therefore introduce new dependencies) on the core. Managing such > dependencies is a nightmare evein with git submodules; it only works if > the git history is shared. This problem is not theoretical, it already > has a bad effect on edk2-platforms. > > For a recent example, my latest OvmfPkg patch series: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c18 > > merged as commit range 61d3b2d4279e..1158fc8e2c7b, started by improving > the logging in MdeModulePkg/PiSmmCore (a1ddad95933e), and fixing a bug > in UefiCpuPkg/PiSmmCpuDxeSmm (90e11edd16c7). > > I don't necessarily mind if *new* virtual platforms are outside of the > edk2 tree, but if I'm completely honest about "why", it's because I > don't use those new platforms. And that's a *selfish* reason -- if I > want ArmVirtPkg and OvmfPkg to benefit from sharing and interleaving > their histories with the core, then other virtual platforms deserve the > same, even if I don't use them. > > (In fact, I think that even edk2-platforms should never have been split > out of edk2 -- but that ship has sailed. I believe I argued against > separating edk2-platforms, but my reasons weren't strong or convincing > enough.) > Yes, keeping platforms in sync with the core is more painful than it should be. If we move all platforms out of the core, what are we going to do for validation? Sure, we'll get a nice tickbox from Azure that all the semicolons line up nicely, but being able to build something that can be tested on actual hardware is essential IMO.