From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web12.10323.1583567587551032070 for ; Fri, 06 Mar 2020 23:53:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=G34/zSR6; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583567586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u+lBjzklWYafKPvq83EOKKqcAwUs2iw0mj9q/dHzXDg=; b=G34/zSR6GUgW3CiWOlyO2/eAvhbj9Rmg1PLsiam9njDjaI/VliJoRmdaXLlogJlFnEZcmb RWv/I1mO4a4giukTHkp6vcqY9M/S8Y3uDh+ESmFxKJpepfUCAsWNMLv5WFCLi2Kpi9Wx1J KKgcYmVSPr5rALQ8DLuJn400JuuPNy0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-112-sBSD52pIPyejEp6dX2s6xw-1; Sat, 07 Mar 2020 02:53:04 -0500 X-MC-Unique: sBSD52pIPyejEp6dX2s6xw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7C743100550D; Sat, 7 Mar 2020 07:53:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-30.ams2.redhat.com [10.36.116.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id CEA16271A1; Sat, 7 Mar 2020 07:53:01 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 From: "Laszlo Ersek" To: "Yao, Jiewen" , "devel@edk2.groups.io" , "rebecca@bsdio.com" , "Justen, Jordan L" , Ard Biesheuvel References: <15F9E16A0219E7B7.19404@groups.io> <74D8A39837DF1E4DA445A8C0B3885C503F972D92@shsmsx102.ccr.corp.intel.com> Message-ID: Date: Sat, 7 Mar 2020 08:53:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/07/20 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. > > 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. > > [...] ... now I expect this might raise the question why my stance on consuming submodules in edk2 itself is different -- i.e., why it is that I *like* edk2 to consume OpenSSL, brotli (TianoCore#2558, TianoCore#2559), Oniguruma (TianoCore#2073) etc through git submodules. Here's why: because we mostly treat those projects as black boxes. - The contributor audiences for those projects hardly overlap with edk2 developers. - The development workflows sharply differ. - The rate of change introduced into those projects, for addressing consumer (i.e., edk2) needs, is very low. This is very much not the case between edk2, and: ArmVirtPkg and OvmfPkg (and, again edk2-platforms). Thanks Laszlo