Re: [edk2-devel] Adding Bhyve support into upstream EDK2

["Laszlo Ersek" <lersek@redhat.com>]

On 03/24/20 02:34, Rebecca Cran wrote:
> On 3/6/20 6:29 PM, Yao, Jiewen wrote:
>> Can you post the patch? :-)
> 
> Thanks, It's just about ready for review I think. There's perhaps a bit
> more deduplication between BhyvePkg and OvmfPkg to be done.
> 
> Since the patch is 1.7MB, I've uploaded it to
> https://bex.dev/bhyve-edk2-stable202002.diff .

Umm... :) This is way too large, I think.

Just because I indeed recommend creating a separate BhyvePkg, it's
really not advisable to create a complete copy of OvmfPkg, as first
step. I assume most modules can be reused from under OvmfPkg; can't they?

Consider for example ArmVirtPkg. The ArmVirtQemu DSC and FDF files refer
to a bunch of content that resides under OvmfPkg. That's what BhyvePkg
should do too:

- introduce its own DEC, DSC and FDF files,
- reuse everything possible verbatim from under OvmfPkg,
- if changes are necessary:
  - tweak existent OvmfPkg PCDs in the BhyvePkg DSC file,
  - introduce new library instances for library classes,
    and link those into OvmfPkg modules (and any other edk2 modules) via
    the BhyvePkg DSC file,
  - in the worst case, copy a *small* subset of OvmfPkg modules, and
    tweak the source under BhyvePkg.
- add totally BHYVE specific modules (drivers) under BhyvePkg.

Basically any given platform (DSC / FDF) is supposed to cherry-pick
whatever it can reuse from edk2 -- that's why edk2 is a "kit". And
virtual platforms are most welcome to depend on (consume modules from)
OvmfPkg.

Again, it's impossible to tell in advance, but in some cases, the tweaks
might be minimal enough to upstream them into OvmfPkg (conditionally on
a PCD, or conditionally on some small / easy runtime detection of
BHYVE). Then BhyvePkg only has to activate said PCD (or just rely on the
runtme detection). Again, there's no general rule; it depends on how
much the bhyve specifics would complicate the OvmfPkg code.

Thanks,
Laszlo