Re: Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg?

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

On 05/11/20 18:36, Kinney, Michael D wrote:
> I agree that ArmVirtPkg contents should be added to OvmfPkg.

I guess "OvmfPkg/Secondary/Bhyve" would be a compromise.

(I would actually prefer "Staging" to "Secondary", according to the following definition:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig

menuconfig STAGING
	bool "Staging drivers"
	---help---
	  This option allows you to select a number of drivers that are
	  not of the "normal" Linux kernel quality level.  These drivers
	  are placed here in order to get a wider audience to make use of
	  them.  Please note that these drivers are under heavy
	  development, may or may not work, and may contain userspace
	  interfaces that most likely will be changed in the near
	  future.

	  Using any of these drivers will taint your kernel which might
	  affect support options from both the community, and various
	  commercial support organizations.

	  If you wish to work on these drivers, to help improve them, or
	  to report problems you have with them, please see the
	  drivers/staging/<driver_name>/TODO file to see what needs to be
	  worked on, and who to contact.

	  If in doubt, say N here.

However, edk2 already uses a separate "staging" repo in (nearly) the same sense, so I figure the "staging" term is already taken. Hence "Secondary", or even "SecondClass".)

Thanks
Laszlo

>> -----Original Message-----
>> From: Ard Biesheuvel <ard.biesheuvel@arm.com>
>> Sent: Monday, May 11, 2020 9:21 AM
>> To: Laszlo Ersek <lersek@redhat.com>; Rebecca Cran
>> <rebecca@bsdio.com>; edk2-devel-groups-io
>> <devel@edk2.groups.io>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
>> Andrew Fish <afish@apple.com>; Leif Lindholm
>> <leif@nuviainc.com>; Justen, Jordan L
>> <jordan.l.justen@intel.com>
>> Subject: Re: Where to put the bhyve code in the edk2
>> repo: BhyvePkg, or under OvmfPkg?
>>
>> 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.
>>
>