Just saw Laszlo's email. Similar feedback. Especially, I like the regression test part.
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) > -----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 (#55627): https://edk2.groups.io/g/devel/message/55627 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] -=-=-=-=-=-=-=-=-=-=-=-
