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:ler...@redhat.com] > Sent: Friday, October 28, 2016 2:22 PM > To: Duran, Leo <leo.du...@amd.com>; edk2-de...@ml01.01.org > Cc: michael.d.kin...@intel.com; jeff....@intel.com; liming....@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
