[edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg?

[Ard Biesheuvel]

On 5/11/20 5:55 PM, Laszlo Ersek wrote:
> (CC'ing Ard and Jordan.)
> 
> On 05/08/20 17:44, Rebecca Cran wrote:
>> During the Community Meeting last night, I was asked to send this email
>> starting a discussion about where to put the bhyve code in the edk2
>> tree: whether it should be in a new BhyvePkg, or added under OvmfPkg.
> 
> I prefer a top-level BhyvePkg.
> 
> If most edk2 consumers wouldn't like to see a top-level BhyvePkg
> directory, I can certainly live with OvmfPkg/Bhyve.
> 
> I can also live with OvmfPkg/Bhyve*, OvmfPkg/Library/Bhyve*, etc, modules.
> 
> So I guess these would be my choices in decreasing order of preference.
> (To be clear, I consider my option#3 still a lot better than not having
> bhyve support in upstream edk2 at all.)
> 
> In either case, "Maintainers.txt" should get a new section listing the
> bhyve-specific modules as being under your and Peter Grehan's
> reviewership ("R").
> 
>> It
>> appears it's already been decided it should be in edk2 along with the
>> other virtual platforms and not edk2-platforms, where code for physical
>> platforms will reside.
> 
> I haven't been aware that this is a done deal, but if it is, it makes me
> glad! I've always wanted bhyve stuff to be in edk2 and not in
> edk2-platforms.
> 

I think it is a good thing to have support for virtual platforms in core 
EDK2, given that such a platform is only a download away for anyone who 
wants to try it. I am strongly opposed to the idea that core EDK2 should 
just be a repository of bits and pieces that platforms can incorporate, 
especially because it can make regressions unsolveable once we get 
ourselves into a state where reverting some patch fixes a problem on one 
platform and creates one on another.

However, I don't think every platforms in core EDK2 can be a first class 
citizen. There is simply no way we can expect contributors to make sure 
that their changes don't break under Bhyve, and the same will be true 
once (if) we merge kvmtool guest support, which is under development as 
well (given that it supports virtualization only, and so unlike QEMU, 
which supports emulation as well, it requires a native host)

So I agree that it makes sense to incorporate Bhyve into core EDK2, but 
we have to decide on some rules regarding 'second class' platforms: 
how/when to test them, and how urgently we treat regressions found 
during such testing. We can treat ArmVirtXen the same way, imo, as well 
as KvmTool when it lands.

Whether we create a BhyvePkg depends on our future intent wrt merging 
OVMF with other virtual platforms. I think it would make sense for the 
ArmVirtPkg and OvmfPkg to be merged at some point, at which time it will 
probably make little sense to have a separate BhyvePkg. But I'm not sure 
what Laszlo's take is on this.

In summary, I can live with any of these options, as long as the 
underlying rules and assumptions are clarified.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#59135): https://edk2.groups.io/g/devel/message/59135
Mute This Topic: https://groups.io/mt/74075377/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-