Re: LocalApicLib: Why two separate directories?

[Laszlo Ersek <lersek@redhat.com>]

On 10/28/16 21:03, Duran, Leo wrote:
> All,
> Just a quick observation to request comments:
> 
> Since a lot of the code in BaseXApicX2ApicLib.c and BaseXApicLib is
> the same, how about we merge the common code and build the libraries
> from the same directory?
> 
> UefiCpuPkg/Library/LocalApilLib/
> - LocalApicLib.c --> common code
> - BaseXApicLib.c --> legacy APIC code
> - BaseXApicX2ApicLib.c --> X2APIC code
> - BaseXApicLib.inf -> builds from LocalApicLib.c + BaseXApicLib.c
> - BaseXApicX2ApicLib.inf -> builds from LocalApicLib.c + BaseXApicX2ApicLib.c
> 
> Of course, doing this would require modification to existing .DSC files, to point to the appropriate .INF under the merged LocalApicLib directory.
> Would that be too disruptive?

In my opinion, if:
- you post all the patches (for all affected platforms) in a series,
- keep the series bisectable (i.e., all the platforms build at any stage
throughout the series),
- CC the relevant maintainers,
- and they accept (R-b) the patches,

then it should be fine.

Conversions like this usually involve creating a copy with the existent
(or to-be-migrated) functionality in the new place, gradually pointing
the platform DSCs to that place, and once the old INF files / library
instances become unreferenced, they are removed in the last patches.

For simpler (Pkg-internal) code movement this is not always necessary
(you can usually solve it all within a single atomic patch, like the one
you just posted). However, when multiple Pkgs (with multiple sets of
maintainers) are affected, we mostly avoid patches that would
simultaneously straddle two or more Pkgs.

It's almost always possible to structure a series like described above
-- modify just one Pkg per step, gradually flipping the pointers from
"old" to "new", and when "old"'s refcount goes to zero, remove "old".

(Clearly the actual answer comes from the UefiCpuPkg maintainers; I'm
just talking about the process.)

Thanks!
Laszlo