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.
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.)
Thanks,
Laszlo
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
>> Sent: Saturday, March 7, 2020 9:30 AM
>> To: devel@edk2.groups.io; rebe...@bsdio.com; Laszlo Ersek
>> <ler...@redhat.com>; Justen, Jordan L <jordan.l.jus...@intel.com>; Ard
>> Biesheuvel <ard.biesheu...@linaro.org>
>> Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2
>>
>> I can share some of my experience, for your information only.
>>
>> 0) If the patch is generic, not specific to Bhyve, but benefit to current
>> EDKII pkg,
>> you can submit them directly. No need to wait for Bhyve.
>>
>> 1) If the patch is very simple, you can merge into current PKG with current
>> DSC.
>> If there is something special to the Bhyve that can be detected at runtime,
>> then
>> detect at runtime.
>> If there is something special to the Byhve that need to be determine at build
>> time, then you can introduce a PCD (such as PcdBhyveXXX) and configurate at
>> build time.
>>
>> 2) If the patch is big, you can introduce a standalone driver and put to
>> current
>> PKG and introduce a new DSC file (such as OvmfBhyve.dsc). You can control and
>> build Byhve with the new DSC file.
>>
>> 3) If the patch is extremely big and has architecture difference, you can
>> introduce a new pkg (BhyvePkg) and put all new drivers there. You can still
>> refer
>> to some drivers in OvmfPkg, which introduce a dependency (BhyvePkg =>
>> OvmfPkg). The OvmfPkg change may impact BhyvePkg build or running.
>>
>> X) Last but not least important, if the Bhyve has a different *security
>> requirement* or *threat model* with current Pkg, then you had better
>> introduce
>> a new pkg or update the current Pkg with same threat model. Before that, you
>> had better not use any driver in other package and keep them separate. It is
>> easy
>> for future audit purpose.
>>
>> Above is the generic rule. I think OvmfPkg maintainer can provide more
>> comment on that.
>>
>> Can you post the patch? :-)
>>
>> Thank you
>> Yao Jiewen
>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca
>>> Cran
>>> Sent: Saturday, March 7, 2020 12:10 AM
>>> To: devel@edk2.groups.io; Laszlo Ersek <ler...@redhat.com>; Justen, Jordan
>> L
>>> <jordan.l.jus...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>
>>> Subject: [edk2-devel] Adding Bhyve support into upstream EDK2
>>>
>>> I'm currently working on updating EDK2 support for Bhyve
>>> (https://bhyve.org/) from the edk2-stable201903 tag to
>>> edk2-stable202002. It's currently kept in a separate repo
>>> (https://github.com/freebsd/uefi-edk2), but I'd like to discuss pushing
>>> support upstream into the main edk2 repo (I guess into edk2-staging as a
>>> first step?).
>>>
>>>
>>> Would that be something people would be open to considering, or should
>>> it remain separate? Should it be a new top-level package (e.g. BhyvePkg)
>>> or could it be just a configuration option when building OVMF? It's
>>> currently maintained as a set of patches against OvmfPkg, which seems to
>>> work quite well.
>>>
>>>
>>> --
>>> Rebecca Cran
>>>
>>>
>>>
>>>
>>
>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55631): https://edk2.groups.io/g/devel/message/55631
Mute This Topic: https://groups.io/mt/71776477/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
