I agree that ArmVirtPkg contents should be added to OvmfPkg.
Mike
> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheu...@arm.com>
> Sent: Monday, May 11, 2020 9:21 AM
> To: Laszlo Ersek <ler...@redhat.com>; Rebecca Cran
> <rebe...@bsdio.com>; edk2-devel-groups-io
> <devel@edk2.groups.io>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> Andrew Fish <af...@apple.com>; Leif Lindholm
> <l...@nuviainc.com>; Justen, Jordan L
> <jordan.l.jus...@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.
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#59139): https://edk2.groups.io/g/devel/message/59139
Mute This Topic: https://groups.io/mt/74075377/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
