From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe42::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4978081DDF for ; Fri, 28 Oct 2016 12:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector1-amd-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vEjifyO5Q4IXZkDFjZNG5kIwPHgvLWTkN2C/2ZWOSkE=; b=fPNkCqZhbshFf7pxJqzipccOP88WjN/cnGdqpgR4dRqU1x8DD7g4Usvimjh+4x5XqY2nuNl216S97Hsnw9tGABGMV5pQn6Mj8fkouQ5OzDCG7UFG2y3ZNHz1P4IWldiKf+cz4jD1vbRXQjRAyg1VaI/JbAo40Q53Q22197hPmps= Received: from DM5PR12MB1243.namprd12.prod.outlook.com (10.168.237.22) by DM5PR12MB1244.namprd12.prod.outlook.com (10.168.237.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Fri, 28 Oct 2016 19:31:16 +0000 Received: from DM5PR12MB1243.namprd12.prod.outlook.com ([10.168.237.22]) by DM5PR12MB1243.namprd12.prod.outlook.com ([10.168.237.22]) with mapi id 15.01.0679.018; Fri, 28 Oct 2016 19:31:16 +0000 From: "Duran, Leo" To: 'Laszlo Ersek' , "edk2-devel@ml01.01.org" CC: "michael.d.kinney@intel.com" , "jeff.fan@intel.com" , "liming.gao@intel.com" Thread-Topic: LocalApicLib: Why two separate directories? Thread-Index: AdIxTgPHfJzAAk7nTwONwEQmJGazqwAApZUAAAAemtA= Date: Fri, 28 Oct 2016 19:31:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=leo.duran@amd.com; x-originating-ip: [165.204.77.1] x-ms-office365-filtering-correlation-id: 773eb6c0-f638-4dd3-db81-08d3ff68fc90 x-microsoft-exchange-diagnostics: 1; DM5PR12MB1244; 7:mhHTZhQkvGmiKc4joDX1qoNOHd8cgkFhkqm1Z4naJmzw+ykKIzL383HcWNe5RcSeaUQ+7cpig81eLT0y3cHJ/GsQ7ZaDef6+gQeH0WXIRjkw+z2fcPcHEY+UsbL8b8bRm2ebhRgt5opQ1W3XPVRynBfvzA6aHs8yxwzfMEsR6IwwB5Bq5EocJXPlPLS1Jvv74iDB8Bslecgxze7p9itmckZjWSzDFRfjx37Kaknxbs67LFIcNQcUjSaQ6mY4C6l3g6ETzlPXih0FfYfSTGvDy/ijp9M44bG98SYTIWhWIU1y4kYoETr1gimIX7i3uiUvomVn64u9w7dQG8ecsl9L16CpW8dlTWcApLf4nt/EnYk=; 20:q4yjmANVzPLASZDhHfoBQm7EBSgdI0KZIadw1m1RMuWOUASe0tsyNvlSN/hxZJOMoa6mGVpJLSF767jFTIMCfF3fP9yg5yeQuvbuBGEyYHTWrQvzEmlUdIHKM4sGCXSPw7N+RAIu0EoXGjyExzkp56occo+zjugAkVQXh9AJNPTd4Dd87bYmO8LauL/2PVJR4gPW4VqtYN8Jj/e7MG1Cfn4sK5Ga8irQb7I5tQD9ivi441/5AoBCG+rypSBr1COw x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1244; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(767451399110)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM5PR12MB1244; BCL:0; PCL:0; RULEID:; SRVR:DM5PR12MB1244; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(13464003)(199003)(377454003)(33656002)(81156014)(101416001)(76176999)(54356999)(106356001)(77096005)(19580405001)(8676002)(19580395003)(2900100001)(105586002)(99286002)(3846002)(9686002)(2906002)(81166006)(6116002)(8936002)(189998001)(102836003)(3660700001)(50986999)(586003)(3280700002)(5001770100001)(122556002)(11100500001)(97736004)(4326007)(87936001)(2950100002)(5002640100001)(7736002)(68736007)(74316002)(76576001)(2501003)(7696004)(66066001)(5660300001)(92566002)(7846002)(10400500002)(305945005)(86362001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1244; H:DM5PR12MB1243.namprd12.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: amd.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2016 19:31:16.6994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1244 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:31:17 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ; 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? >=20 > 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? >=20 > 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, >=20 > then it should be fine. >=20 > Conversions like this usually involve creating a copy with the existent (= or to- > be-migrated) functionality in the new place, gradually pointing the platf= orm > DSCs to that place, and once the old INF files / library instances become > unreferenced, they are removed in the last patches. >=20 > For simpler (Pkg-internal) code movement this is not always necessary (yo= u > can usually solve it all within a single atomic patch, like the one you j= ust > posted). However, when multiple Pkgs (with multiple sets of > maintainers) are affected, we mostly avoid patches that would > simultaneously straddle two or more Pkgs. >=20 > It's almost always possible to structure a series like described above > -- modify just one Pkg per step, gradually flipping the pointers from "ol= d" to > "new", and when "old"'s refcount goes to zero, remove "old". >=20 > (Clearly the actual answer comes from the UefiCpuPkg maintainers; I'm jus= t > talking about the process.) >=20 > Thanks! > Laszlo