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....@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 > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55718): https://edk2.groups.io/g/devel/message/55718 Mute This Topic: https://groups.io/mt/71776477/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
