Hi Laszlo, Is there an option for Bhyve to live in an edk2-platforms branch or in edk2-staging branch until it meets the quality criteria for OvmfPkg in the edk2 repo?
Mike > -----Original Message----- > From: Laszlo Ersek <ler...@redhat.com> > Sent: Monday, May 11, 2020 2:12 PM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Ard > Biesheuvel <ard.biesheu...@arm.com>; Rebecca Cran > <rebe...@bsdio.com>; edk2-devel-groups-io > <devel@edk2.groups.io> > Cc: 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 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/torvald > s/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.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 (#59209): https://edk2.groups.io/g/devel/message/59209 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] -=-=-=-=-=-=-=-=-=-=-=-
