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

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

On 05/14/20 19:48, Sean Brogan wrote:

> Adding another platform to a core repository that might or might not
> work at any given time is a burden to all core contributors and doesn't
> bring value to the core project.

Platforms that depend on edk2, but are not inside edk2, are near
guaranteed to break when core edk2 changes occur. Such external
dependencies are impossible to locate with "git grep"; you can't run a
git-grep on "all projects in the universe that consume edk2".

Even if you manage to identify some high-profile out-of-tree platforms
(by sheer diligence, or by those platforms' own CI systems -- doesn't
matter), you are effectively prevented from adjusting them in the *right
patch order*, as you cannot cover multiple repositories in a single
patch series.

This is already causing *massive* and everyday pain with edk2-platforms;
contributions that would normally take the form of a run-of-the-mill
patch series, now have to be split in at least three waves (prepare the
core, update external platforms, switch over the core). With in-tree
platforms, the approach is of course the same, the difference is that
these stages can be managed, and merged, in a unified series of commits.
Addressing external dependencies by splitting work into sub-series slows
development to a crawl.

(BaseTools is no exception. I've agreed to splitting it out because the
demand for that seems to be huge, and with careful maintenance of
"pip-requirements.txt", and with the features offered by pip virtual
environments, it appears technically possible. Conceptually, with these
bits in place, the BaseTools <-> edk2 dependency tracking should not
lose any safety. It *will* lose efficiency.)


Furthermore , I disagree with your "burden to all core contributors" and
"doesn't bring value to the project" statements 100%.

- I *am* a core contributor (feel free to look up the patches I've
contributed, with git-log),
- DynamicTablesPkg, EmulatorPkg, FmpDevicePkg, IntelFsp2Pkg,
IntelFsp2WrapperPkg, SignedCapsulePkg, SourceLevelDebugPkg,
StandaloneMmPkg, UefiPayloadPkg, UnitTestFrameworkPkg carry exactly zero
interest for me,
- but they are also exactly zero burden to me.

So your statement "burden to all core contributors" is false
(EmulatorPkg in particular is a platform which sometimes does break),
and it does not bother me at all.

Then, having bhyve in-tree *does* bring value to the project, because it
simplifies the testing and development of core edk2 modules on a new,
thus far not officially targeted, hypervisor platform. It exposes edk2
to a wider audience; people using FreeBSD as their everyday desktop will
have an easier time running and hopefully developing edk2.

Laszlo