Re: [edk2-devel] Adding Bhyve support into upstream EDK2

["Ard Biesheuvel" <ard.biesheuvel@linaro.org>]

For me, the issue is more fundamental than what Laszlo describes.

The platforms that target qemu, which is available to anyone, can run
on any host, and can boot various OSes beyond Linux (including
windows), which is their primary target. It even supports
virtualization, which is highly significant on arm, given the tricky
cache maintenance and things like aligned access and dc zva
instructions, which qemu does not catch in emulation mode.

This means we can reasonably require any contributor not to regress on
those platforms, given how they have full access to it, and this is
actually where i would like us to take the next step when it comes to
ci automation, i.e., automatically flag PRs that break the boot on a
selected set of qemu based configs.

Putting those platforms in a separate repository complicates this to
the extent where it is no longer feasible to reason about the core
repository being in a working or broken state, given how intrusive
changes usually require changes on the platform description side as
well, and I don’t see the validation  tools handling two repositories
in parallel.

Beyond this, i have no fundamental objections to moving  things out of
the core, and i’d remove more cruft from ArmPlatformPkg or EmbeddedPkg
if i could (including, e.g., the PrePi SEC code that should have never
existed)



On 10/03/2020, Sean via Groups.Io <sean.brogan=microsoft.com@groups.io> wrote:
> I don't see the difference besides the mechanics of the operation (which you
> have described clearly).  To guarantee a repo or repos is "git-bisectable"
> you need to build and test every commit on your platform.  For example in
> the recent ArmMmuLib patchset, you were able to build every commit in the
> patch to identify which one caused the break.  There isn't an enforced
> process in place to ensure that happens within Edk2.  Thankfully the review
> process and the developers knowledge allowed the commits to be made in such
> a way that this was possible.  That doesn't have to change when you move to
> a submodule.  Also you could put automation in place to enforce and/or test
> for this scenario.  You can put automation in place to "integrate" into your
> super project at every commit if you really wanted to and had the resources
> to run tests on every one of those commits.  Is this type of CI done today
> for OVMF?
>
> Again this is what nearly all platforms have to do today and we have a lot
> of experience with bisecting within the submodule to find the error.  The
> longer you wait between integrations the more costly the bisect is if you
> have to do it, but this is a choice of the super project owner / platform
> owner.  Today I assume you make those choices too, they just happen to be
> within the same repo.  I also assume that if you found the MmuLib bug in a
> few days you probably wouldn't bisect all the changes but you would review
> the history to intelligently guess at the most likely candidates and bisect
> within those commits.
>
> In the end I just don't see the big difference to the platform (OVMF in this
> case) but I do see the reduced size/noise/content helping all platforms.
> Success still relies on good development practices, regular builds, and
> testing.
>
> Thanks
> Sean
>
> 
>
>