From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.24, mailfrom: liming.gao@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by groups.io with SMTP; Mon, 23 Sep 2019 18:28:30 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2019 18:28:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,542,1559545200"; d="scan'208";a="339919443" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 23 Sep 2019 18:28:29 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Sep 2019 18:28:29 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Sep 2019 18:28:28 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.32]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0439.000; Tue, 24 Sep 2019 09:28:27 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "leif.lindholm@linaro.org" , Laszlo Ersek CC: Baptiste Gerondeau , "ard.biesheuvel@linaro.org" , "Kinney, Michael D" , "Zhang, Shenglei" Subject: Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio Thread-Topic: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio Thread-Index: AQHVbs7lIJ7Wq5loa0OkbIs5T07ypacy2+uAgAARn4CABx8acA== Date: Tue, 24 Sep 2019 01:28:27 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E50051E@SHSMSX104.ccr.corp.intel.com> References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4FE630@SHSMSX104.ccr.corp.intel.com> <20190919094450.GN28454@bivouac.eciton.net> <20190919202719.GB28454@bivouac.eciton.net> In-Reply-To: <20190919202719.GB28454@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leif: >-----Original Message----- >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Lei= f >Lindholm >Sent: Friday, September 20, 2019 4:27 AM >To: Laszlo Ersek >Cc: devel@edk2.groups.io; Gao, Liming ; Baptiste >Gerondeau ; ard.biesheuvel@linaro.org; >Kinney, Michael D ; Zhang, Shenglei > >Subject: Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio > >On Thu, Sep 19, 2019 at 09:24:15PM +0200, Laszlo Ersek wrote: >> On 09/19/19 11:44, Leif Lindholm wrote: >> > I agree with this as a general rule, but for this (hopefully never to >> > be repeated) operation, it makes sense to me to keep each change in >> > this set as one patch. >> > >> > For the simple reason that the alternative leaves several unusable >> > commits in sequence in the repository. There is simply no way to >> > bisect through this change on a per-package basis. >> > >> > This is after all a horrible horrible hack that lets us keep using th= e >> > .asm files provided for one toolchain family (RVCT) in a different >> > toolchain family (MSFT), without having to delete and re-add, losing >> > history in the process. >> > >> > Would you be OK with an exception for this extremely unusual >> > situation? >> >> (The question was posed to Liming, but I'm going to follow up here with >> my own thoughts, after getting CC'd by Liming. Thanks for that BTW.) > >Yes, I should have thought of that myself - Baptiste did exactly what >I asked him to. > >> Let's assume the changes are split up with a fine granularity. Under >> that assumption, consider two cases: >> >> (1) ARM builds on Visual Studio are broken until the last patch is >> applied, but all other toolchains continue working fine throughout the >> series. >> >> versus >> >> (2) ARM builds are broken on Visual Studio *and* on at least one other >> -- preexistent -- toolchain, until the last patch in the series is appl= ied. >> >> >> Which case reflects reality? >> >> If it's case (1), then I prefer the fine-grained patch series structure= . >> Nothing regresses with existent toolchains (so bisection works with >> them), we just have to advertise the last patch in the series as the on= e >> that enables Visual Studio. >> >> If it's case (2), then I agree with the larger (multi-package) patch, a= s >> a rare exception. >> >> (We can also put it like this: if it's *possible* to write this series >> such that it enables (1), then we should strive for that.) > >I agree with your logic. >It's just that I'm not even aware of anyone who has *tried* building >with RVCT for several years. So we leave the "probably not working" >toolchain potentially working for a few more commits, as a tradeoff >against enabling the new one in one go. > >(Now, fair, there are other issues with the VS ARM port that as per >the cover letter will also need to be addressed before the port is >fully functional.) > If RVCT doesn't work, this change will follow into case (1). Right?=20 Thanks Liming >/ > Leif > >