Re: LocalApicLib: Why two separate directories?

["Duran, Leo" <leo.duran@amd.com>]

Thanks Lazlo.

The process as you described it makes a lot of sense.
However, I worry about the effect on external consumers of EDK2 once "old" is removed.

Leo.


> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, October 28, 2016 2:22 PM
> To: Duran, Leo <leo.duran@amd.com>; edk2-devel@ml01.01.org
> Cc: michael.d.kinney@intel.com; jeff.fan@intel.com; liming.gao@intel.com
> Subject: Re: LocalApicLib: Why two separate directories?
> 
> 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