From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=OUClSOZb; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by groups.io with SMTP; Thu, 19 Sep 2019 12:57:37 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x8JJuxp3047697; Thu, 19 Sep 2019 12:57:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/P6/bZ/pMplKjuX8DdBIzLwyYTzbv4TJ+WjwkeFkb+A=; b=OUClSOZbvX7CAbOBiJ2ntD/bku+efIrTtGau41OrNBDTzp2R2XIiEIgUMA8QWQFsYJrn UwOPPBejBG+Razht7h0CE9Tx/S6X7WxL+F3HvITQIrOylBh1unR52GW+2rBizKooOGGI +8WasI4Sqha/SOO4uA7QgQMotd5PwjlUlGCXu4HITS7Q6aJMJSqyRo39pHhkv+mKozjk gB8jupUTvfnonixeYmDxszvzfAnIkp41O7nUKdbHXSd9nrt4a/NRPTwN3Djd+KwuHu6e Vp6LVEL/g9YVLp8rW6jnNYxnLTEpSlwkU2MpxVij3/yAZ4UVRpmB3Iw47y2l/vmKzxy+ FQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2v3va1kubv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Sep 2019 12:57:34 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PY3000MNGRX7U50@ma1-mtap-s03.corp.apple.com>; Thu, 19 Sep 2019 12:57:34 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PY300900FUUF600@nwk-mmpp-sz12.apple.com>; Thu, 19 Sep 2019 12:57:34 -0700 (PDT) X-V-A: X-V-T-CD: 08777febe38bb384cc57fda39d0586b7 X-V-E-CD: 103e1421009cc8f9b395957b53bb597f X-V-R-CD: 09363d49962846dd1759d5a459a6e040 X-V-CD: 0 X-V-ID: d2aeecc1-cf2b-41b8-aecf-e57a0348002b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-19_05:,, signatures=0 Received: from [17.235.36.202] (unknown [17.235.36.202]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PY3007CEGRPPCE0@nwk-mmpp-sz12.apple.com>; Thu, 19 Sep 2019 12:57:28 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <4C16B5F2-BE65-406C-BF39-114DC3495B52@apple.com> MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio Date: Thu, 19 Sep 2019 12:57:25 -0700 In-reply-to: Cc: Leif Lindholm , "Gao, Liming" , Baptiste Gerondeau , "ard.biesheuvel@linaro.org" , Mike Kinney , "Zhang, Shenglei" To: devel@edk2.groups.io, Laszlo Ersek References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4FE630@SHSMSX104.ccr.corp.intel.com> <20190919094450.GN28454@bivouac.eciton.net> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-19_05:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_AE6722C7-6DBE-45B6-AA1A-BCBC89904392" --Apple-Mail=_AE6722C7-6DBE-45B6-AA1A-BCBC89904392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 19, 2019, at 12:24 PM, Laszlo Ersek wrote: >=20 > On 09/19/19 11:44, Leif Lindholm wrote: >> Hi Liming, >>=20 >> On Thu, Sep 19, 2019 at 06:19:42AM +0000, Gao, Liming wrote: >>> I add my comments.=20 >>>=20 >>>> -----Original Message----- >>>> From: Baptiste Gerondeau [mailto:baptiste.gerondeau@linaro.org] >>>> Sent: Thursday, September 19, 2019 12:05 AM >>>> To: devel@edk2.groups.io >>>> Cc: ard.biesheuvel@linaro.org; leif.lindholm@linaro.org; Kinney, Mich= ael D >>>> ; Gao, Liming ; Zha= ng, >>>> Shenglei ; Baptiste Gerondeau >>>> >>>> Subject: [PATCH 0/3] Arm builds on Visual Studio >>>>=20 >>>> EDIT: Resending the series since I mistakenly used the wrong email, >>>> sorry ! >>>>=20 >>>> We are currently making an effort to make ARM (and AARCH64 eventually= ) >>>> builds using Microsoft's Visual Studio Compiler (aka MSVC/MSFT). >>>>=20 >>>> These 3 patches correspond to an effort to make the assembler work wi= th >>>> MSFT, which entails : >>>> - Feeding MSFT the RVCT .asm files, since they share syntax >>>> requirements. >>>=20 >>> Please separate the patch. Each patch is for each package, can't cross= packages.=20 >>> If so, the package maintainer can easy review the change.=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> This is after all a horrible horrible hack that lets us keep using the >> .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. >>=20 >> Would you be OK with an exception for this extremely unusual >> situation? >=20 > (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.) >=20 > Let's assume the changes are split up with a fine granularity. Under > that assumption, consider two cases: >=20 > (1) ARM builds on Visual Studio are broken until the last patch is > applied, but all other toolchains continue working fine throughout the > series. >=20 > versus >=20 > (2) ARM builds are broken on Visual Studio *and* on at least one other > -- preexistent -- toolchain, until the last patch in the series is appli= ed. >=20 >=20 > Which case reflects reality? >=20 > 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 one > that enables Visual Studio. >=20 > If it's case (2), then I agree with the larger (multi-package) patch, as > a rare exception. >=20 > (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.) >=20 Laszlo, I agree with your logic around (1) and (2). I'd also point out we can do t= he review using (1) and squash into a single commit if we need to take path= (2). Thanks, Andrew Fish > Thanks, > Laszlo >=20 >=20 --Apple-Mail=_AE6722C7-6DBE-45B6-AA1A-BCBC89904392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 19= , 2019, at 12:24 PM, Laszlo Ersek <lersek@redhat.com> wrote:

On 09/19/19 11:44, Leif Lindholm wrote= :
Hi Limin= g,

On Thu, Sep 19, 2019 at 06:19:42AM +0000, G= ao, Liming wrote:
I add = my comments. 

-----Original Messag= e-----
From: Baptiste Gerondeau [mailto:baptiste.gerondeau@linaro.org]Sent: Thursday, September 19, 2019 12:05 AM
To: = devel@edk2.groups.io=
Cc: = ard.biesheuvel@linaro.org; leif.lindholm@linaro.org; Kinney, Michael D
&l= t;michael.d.kinney= @intel.com>; Gao, Liming <liming.gao@intel.com>; Zhang,
Shenglei <= ;shenglei.zhang@inte= l.com>; Baptiste Gerondeau
<baptiste.gerondeau@linaro.org><= br class=3D"">Subject: [PATCH 0/3] Arm builds on Visual Studio

EDIT: Resending the series since I mistakenly used the wro= ng email,
sorry !

We are current= ly making an effort to make ARM (and AARCH64 eventually)
buil= ds using Microsoft's Visual Studio Compiler (aka MSVC/MSFT).
=
These 3 patches correspond to an effort to make the assemble= r work with
MSFT, which entails :
- Feeding MSF= T the RVCT .asm files, since they share syntax
requirements.<= br class=3D"">

Please separate the patch. Each p= atch is for each package, can't cross packages. 
If so, the package maintainer can eas= y review the change. 

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 patc= h.

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 p= er-package basis.

This is after all a horrible= horrible hack that lets us keep using the
.asm files provide= d for one toolchain family (RVCT) in a different
toolchain fa= mily (MSFT), without having to delete and re-add, losing
hist= ory in the process.

Would you be OK with an ex= ception for this extremely unusual
situation?
<= /blockquote>
(The question was= posed to Liming, but I'm going to follow up here with
my own thoughts, after getting CC'd by Limi= ng. Thanks for that BTW.)

Let's assume the changes are spli= t 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 con= tinue working fine throughout the
series.

versus

(2) ARM builds= are broken on Visual Studio *and* on at least one other
-- preexistent -- toolchain, until the la= st patch in the series is applied.


Which case reflects reality?

If it's case = (1), then I prefer the fine-grained patch series structure.
Nothing regresses with existent toolc= hains (so bisection works with
them), we just have to advertise the last patch in the series as th= e one
that enables Visu= al Studio.

If it's case (2), then I agree with the larger (= multi-package) patch, as
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.)


Laszlo,
=
I agree with your logic around (1) and (2). I'd a= lso point out we can do the review using (1) and squash into a single commi= t if we need to take path (2).

Thanks,<= /div>

Andrew Fish

Thanks,
Laszlo

<= /blockquote>

--Apple-Mail=_AE6722C7-6DBE-45B6-AA1A-BCBC89904392--