From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 12CE781DD3 for ; Fri, 28 Oct 2016 12:22:23 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14522C04B321; Fri, 28 Oct 2016 19:22:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-38.phx2.redhat.com [10.3.116.38]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9SJMLxw020970; Fri, 28 Oct 2016 15:22:21 -0400 To: "Duran, Leo" , "edk2-devel@ml01.01.org" References: Cc: "michael.d.kinney@intel.com" , "jeff.fan@intel.com" , "liming.gao@intel.com" From: Laszlo Ersek Message-ID: Date: Fri, 28 Oct 2016 21:22:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 28 Oct 2016 19:22:23 +0000 (UTC) Subject: Re: LocalApicLib: Why two separate directories? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 19:22:23 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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