Re: [edk2-platforms][PATCH v1 01/02] QemuOpenBoardPkg: Add QemuOpenBoardPkg

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> > That is a rather short description for a patch of this size.  It
> > probably makes sense to break that down into smaller pieces and make a
> > patch series out of it because you can describe the specific pieces much
> > better then.

> I was thinking about breaking down the main patch into smaller ones
> corresponding to MinPlatform stages implementations to make it easier
> to follow along.

Sounds good.  Also one patch per board-specific library or module makes
things easier to review.

> > Why duplicate that lib instead of just using the OvmfPkg version (which
> > you do elsewhere)?

> It was supposed to be for training purposes,

> > Note that OvmfPkg got a PlatformInitLib recently which you might be able
> > to use to reduce code duplication (didn't check the code though and
> > maybe MinPlatform init is different enough that this doesn't help much).

> For both GSOC purposes and MinPlatform compliance, I didn't want this
> package to be OVMF but repacked, PlatformInit from OVMF is very
> complete, maybe too much when we are targeting a simple board port.
> QemuOpenBoardPkg's PlatformInit only performs the necessary and
> nothing more, to make reading and understanding the package easier.

> It's also up to debate, but concerning OVMF code, all the dependencies
> we have with OVMF makes understanding the boot flow a bit harder,

Ok.  Having small & self-contained modules is nice for training and
learning purposes.  The many modules and libraries OVMF has provide more
features and help reduce code duplication, but at times makes it indeed
hard to follow the code control flow.

So if the goal is to have a rather minimal qemu board for training
purpose (and not duplicate all features OVMF has) I think I'm fine
with the approach taken.

> I was thinking about slowly phasing out OVMF modules with lot of
> external dependencies in favor of new ones,

Which ones do you have in mind specifically?

I think it makes sense to continue sharing the drivers (virtio, gop,
...), but those should not have many external dependencies.

take care,
  Gerd