From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web10.10173.1587344646085936667 for ; Sun, 19 Apr 2020 18:04:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=W+I1yMHG; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 03K0vBJC006373; Sun, 19 Apr 2020 18:03:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=QLmuCi8TR36fACWm3RS8Uy/gGA14HUk5KlB/p3fOpL4=; b=W+I1yMHGLubUKdPzzkSo/6kuPfjnWPcpGz5idv65w9MDEBSDxnBGbvL3/RfFB9dK4q+J JxV7JdivOGZ69oQzeW+wtWLTun4Lt2lIFaCAGPZOHVDUi/5WlhhPkkFTYYoaC8Z9HrLF mbOHj02DqR8coOI7dr5cAG84N8AXEaI+X7dt6V/YTmWgQF/oGpaGI2FUwMX2sRM2E1/4 /jeKOBsph9bmFJ0iwbE7SoWJEwPADA9fjTQMbBcWLh5Ggocbuo6gbkap78tKovRYS/DV l3YMHiJeXdE3IY19xjXFYMzEUpbhG/Y6r1IVcpyYXWJKSGZQrOGTYpgARXz3oJSgPYrS AA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp02.apple.com with ESMTP id 30fx4g9d3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 19 Apr 2020 18:03:51 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9200P34AYFJJ30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sun, 19 Apr 2020 18:03:51 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9200L009EXBC00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sun, 19 Apr 2020 18:03:51 -0700 (PDT) X-Va-A: X-Va-T-CD: 678bf7de5df0d9ff994f556fd1b44182 X-Va-E-CD: 9fa4df038bb47f81ff46daaf2673e7ae X-Va-R-CD: e5ea5c14454c739ba36e09a585ce6c81 X-Va-CD: 0 X-Va-ID: 41fa3e36-8463-4b74-a8ad-576253deef7f X-V-A: X-V-T-CD: 678bf7de5df0d9ff994f556fd1b44182 X-V-E-CD: 9fa4df038bb47f81ff46daaf2673e7ae X-V-R-CD: e5ea5c14454c739ba36e09a585ce6c81 X-V-CD: 0 X-V-ID: ffc43031-16b7-48bd-b007-bcc509977ae5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-19_06:2020-04-17,2020-04-19 signatures=0 Received: from [17.235.12.150] (unknown [17.235.12.150]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9200J32AYDGW00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sun, 19 Apr 2020 18:03:50 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Date: Sun, 19 Apr 2020 18:03:49 -0700 In-reply-to: Cc: Pete Batard , Ard Biesheuvel , Samer El-Haj-Mahmoud , Leif Lindholm To: devel@edk2.groups.io, awarkentin@vmware.com References: <20200419130417.3298-1-samer@elhajmahmoud.com> <8d59e616-9910-4935-2e1f-5da75fc1d34a@arm.com> <831705c6-0915-ba1a-adc0-3078b2af1a43@akeo.ie> <28ac6ff0-86eb-fde7-63f6-c1c7dc0f0724@akeo.ie> <2046f801-45c2-f591-fdf8-18e2edb093d3@akeo.ie> <160753416257B0CA.29096@groups.io> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-19_06:2020-04-17,2020-04-19 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_1C2DE312-9F2E-4F08-8FF2-11CB487B08D3" --Apple-Mail=_1C2DE312-9F2E-4F08-8FF2-11CB487B08D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 19, 2020, at 4:50 PM, Andrei Warkentin wr= ote: >=20 > Stepping back, can we do a roll call among stakeholders so we start trea= ting contentious issues as a community? >=20 > So far: >=20 > Samer (implicit, unless he says otherwise, because he proposed the patch= ): +1 > Ard: -1 > Pete: -1 > Andrei: +1 >=20 > Anyone else? >=20 -100 since we don't use a points system :).=20 The process is if the maintainers can not agree we let the Stewards decide= . The next Stewards meeting is May 5th, so in the mean time we can try to r= each consensus as that is our preference for a process.=20 Maybe it would be useful to summarize the issue and state the pro and cons= ? Thanks, Andrew Fish > How many points do folks thing we need for a merge? I'd say +2. >=20 > A > From: devel@edk2.groups.io > on behalf of Andrei Warkentin via gro= ups.io > > Sent: Sunday, April 19, 2020 3:42 PM > To: Pete Batard >; devel@edk2.groups.= io >; Ard Biesheuvel >; Samer El-Haj-Mahmoud > > Cc: Leif Lindholm > > Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Raspber= ryPi : Enable TFTP shell command > > It's part of Tiano, no? We didn't develop it. Yet I see it being used in= many Tiano-derived UEFI implementations in the Arm world. I don't see a co= ntract anywhere that all Tiano implementations ought to avoid components th= at don't fit the UEFI/PI/Shell specs. Can someone point me to such a contra= ct? >=20 > We're entering the "victimless crime" territory here, and also violating= the principle of least surprise. >=20 > I do agree that DEBUG profile may choose a subset of configuration optio= ns, for reasons such as sticking to a smaller configuration (for size, comp= lexity, etc). >=20 > A > From: Pete Batard > > Sent: Sunday, April 19, 2020 3:24 PM > To: Andrei Warkentin >; devel@edk2.groups.io >; Ard Biesheuvel >; Samer El-Haj-Mahmoud > > Cc: Leif Lindholm > > Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Raspber= ryPi : Enable TFTP shell command > > On 2020.04.19 21:21, awarkentin@vmware.com wrote: > > So if I understood correctly: > >=20 > > * If a random person off the street builds edk2 - they don't get TFT= P > > command out of the box >=20 > Yup. For the reasons that Ard pointed out (current TFTP being a=20 > non-standard hack that should be replaced by something more suitable...= =20 > eventually). >=20 > > * Our builds retain TFTP command >=20 > Yup. >=20 > >=20 > > Correct? > > ----------------------------------------------------------------------= -- > > *From:* devel@edk2.groups.io > on behalf of Pete=20 > > Batard via groups.io > > > *Sent:* Sunday, April 19, 2020 3:06 PM > > *To:* devel@edk2.groups.io >; Andrei Warkentin=20 > > >; Ard Biesheuvel= >; Samer=20 > > El-Haj-Mahmoud = > > > *Cc:* Leif Lindholm > > > *Subject:* Re: [edk2-devel] [edk2-platform][PATCH v1 0/4]=20 > > Platform/RaspberryPi : Enable TFTP shell command > > Andrei, > >=20 > > In case this is your concern, please note that we are not removing TFT= P > > support at all, which is enabled for the RELEASE builds we produce and > > will remain so (and which anyone can enable with the macro if they wis= h). > >=20 > > All that will be changed by the updated proposal is that the current > > DEBUG ASSERT will be fixed and TFTP support will remain optional, like > > it is today. > >=20 > > So, in this case, I don't think your concern is warranted, because we'= re > > not actually taking any step to deprive anyone of any functionality th= ey > > might wish for, and, even with the revised patch, TFTP will remain > > enabled in our RELEASE binaries, exactly as it has been before. > >=20 > > Regards, > >=20 > > /Pete > >=20 > > On 2020.04.19 20:56, Andrei Warkentin wrote: > >> Hi folks, > >>=20 > >> If we have to choose abstract goodness over functionality, why wouldn= 't=20 > >> we choose functionality? Functionality that's part of Tiano? The real= = =20 > >> world doesn't care about the TFTP command being an "unsupported hack"= or=20 > >> not. So there's Tiano-specific code here. Big deal? To rephrase=20 > >> differently, why would either Pi 4 developers or Pi 4 UEFI users pay = the=20 > >> cost of Tiano carrying code that somehow isn't "legit enough" to be e= nabled? > >>=20 > >> I mean here we are again, where what goes into the code is being=20 > >> dictated by some abstract ideology instead of technical reasons? > >>=20 > >> A > >> ---------------------------------------------------------------------= --- > >> *From:* Pete Batard > > >> *Sent:* Sunday, April 19, 2020 9:19 AM > >> *To:* Ard Biesheuvel >; Samer El-Haj-Mahmoud=20 > >> >; devel@edk2.= groups.io > > >> *Cc:* Leif Lindholm >; A= ndrei Warkentin=20 > >> > > >> *Subject:* Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi := =20 > >> Enable TFTP shell command > >> On 2020.04.19 14:33, Ard Biesheuvel wrote: > >>> On 4/19/20 3:04 PM, Samer El-Haj-Mahmoud wrote: > >>>> Fix an ASSERT with the TFTP dynamic Shell command on the > >>>> RPi3 and RPi4 when running DEBUG builds. Also, enable the > >>>> command by default for all builds. > >>>> > >>>=20 > >>> Fixing the ASSERT is fine but I am reluctant to enable this by defau= lt. > >>=20 > >> I'm going to second this. > >>=20 > >> To answer a question Samer was asking elsewhere, this is actually par= t > >> of the reason why TFTP is not enabled in the DEBUG builds we produce = at > >> https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Fpftf%2FRPi4&data=3D02%7C01%7Cawarkentin%40vmware.com%7Cff25= 433f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C6= 37229246665197560&sdata=3DrgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3= D&reserved=3D0 =20 > >=20 > >> (See build_firmware.sh), the reasoning > >> being that if someone encounters an issue with RELEASE and we ask the= m > >> to troubleshoot with the DEBUG artifact, we want to eliminate potenti= al > >> troublemakers when they try that. > >>=20 > >>> It is a non-standard hack that ARM contributed in the past, and is n= ot=20 > >>> covered by the EFI of Shell specifications. If RPi4 is intended to b= e a=20 > >>> showcase for UEFI on ARM done right, we should not enable this at al= l. > >>=20 > >> Here I have to point out that RPi4 becoming a showcase because we int= end > >> to is not what we are pursuing (because if it was a matter of "willin= g" > >> a showcase into existence, we would have picked a platform with a lot > >> less quirks, more comprehensive documentation, and so on). > >>=20 > >> Instead, we estimate that due to its price point and widespread > >> availability, it *is* going to become a de facto showcase, whether > >> everybody likes it or not. And that is the reason we want to treat is= as > >> a showcase where possible. > >>=20 > >> Regards, > >>=20 > >> /Pete > >>=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 --Apple-Mail=_1C2DE312-9F2E-4F08-8FF2-11CB487B08D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 19= , 2020, at 4:50 PM, Andrei Warkentin <awarkentin@vmware.com> wrote:

St= epping back, can we do a roll call among stakeholders so we start treating = contentious issues as a community?
So far:

Samer (implicit, unless he says otherwise, because he proposed= the patch): +1
Ard: -1
Pete: -1
Andrei: +1

Anyone else?


-1= 00 since we don't use a points system :). 

The process is if the maintainers can not agree we let the Steward= s decide. The next Stewards meeting is May 5th, so in the mean time we can = try to reach consensus as that is our preference for a process. 
=

Maybe it would be useful to summarize the is= sue and state the pro and cons?


Thanks,

Andrew Fish<= /div>
How many points do folks thing we need for a = merge? I'd say +2.

A
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Andrei W= arkentin via groups.io <awarkentin=3Dvmware.com@groups.io>
Sent: Sunday, = April 19, 2020 3:42 PM
To: Pete Batard <pete@akeo.ie>; devel@edk= 2.groups.io <devel@edk2.groups.io>;= Ard Biesheuvel <ar= d.biesheuvel@arm.com>; Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Cc: = Leif Lindholm <leif@nuvi= ainc.com>
Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 = 0/4] Platform/RaspberryPi : Enable TFTP shell command
 
It's part of Tiano, no? We didn't develop it. Yet I see it being use= d in many Tiano-derived UEFI implementations in the Arm world. I don't see = a contract anywhere that all Tiano implementations ought to avoid component= s that don't fit the UEFI/PI/Shell specs. Can someone point me to such a co= ntract?

We're entering the = "victimless crime" territory here, and also violating the principle of leas= t surprise.

I do agree that= DEBUG profile may choose a subset of configuration options, for reasons su= ch as sticking to a smaller configuration (for size, complexity, etc).

A
From: <= /span>Pete Batard <pete@akeo.= ie>
Sent: Sunday, April 19, 2020 3:24 PM
To: Andrei Wa= rkentin <awarkentin@= vmware.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Ard Biesheuvel <= ard.biesheuvel@arm.com= >; Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Cc:=  Leif Lindholm <leif@nuviainc.com>
Subject:=  Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Raspbe= rryPi : Enable TFTP shell command
 
<= div class=3D"x_BodyFragment">
On 2020.04.19 21:21, awarkentin@vmware.com wrote:
> So if I understood cor= rectly:
> 
>   * If a random person off the street build= s edk2 - they don't get TFTP
>     com= mand out of the box

Yup. For the reasons that = Ard pointed out (current TFTP being a=  
non-standard hack that should be replaced by so= mething more suitable... =
eventually).

>   *= Our builds retain TFTP command

Yup.

> 
> Correct?
> -------------------------= -----------------------------------------------
> *From:*<= span class=3D"Apple-converted-space"> devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Pete 
> Batard via groups.io <pete=3Dakeo.ie@groups.io>
> *Sent:* Sunday, April 19, 2020 3:06 PM
> *To:* devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warkentin 
> <awarkentin@vmware.com&g= t;; Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer 
> El-Haj-Mahmoud <samer@elhajmahmoud.com>
> *Cc:* Leif Lindholm <leif@nuviainc.com>
> *Subject:* Re: [edk2-devel]= [edk2-platform][PATCH v1 0/4] <= /span>
> Platform/RaspberryPi : Enable TFTP shell command<= br class=3D"">> Andrei,
> 
> In case this is your concern, plea= se note that we are not removing TFTP
> support at all, wh= ich is enabled for the RELEASE builds we produce and
> wil= l remain so (and which anyone can enable with the macro if they wish).
> 
> All that will be changed by the updated proposal is that the cu= rrent
> DEBUG ASSERT will be fixed and TFTP support will r= emain optional, like
> it is today.
> 
> So, in t= his case, I don't think your concern is warranted, because we're
> not actually taking any step to deprive anyone of any functiona= lity they
> might wish for, and, even with the revised pat= ch, TFTP will remain
> enabled in our RELEASE binaries, ex= actly as it has been before.
> 
> Regards,
> 
> /Pete
> 
> On 2020.04.19 20:56, Andrei Warkentin wrote:
>= > Hi folks,
>>=  
>> If we have to choose abstract goodness= over functionality, why wouldn't&nbs= p;
>> we choose functionality? Functionality tha= t's part of Tiano? The real 
>> world doesn't care about the TFTP command being = an "unsupported hack" or =
>> not. So there's Tiano-specific code here. Big deal?= To rephrase 
>> differently, why would either Pi 4 developers or Pi 4 UEFI user= s pay the 
= >> cost of Tiano carrying code that somehow isn't "legit enough" to b= e enabled?
>>&nbs= p;
>> I mean here we are again, where what goes = into the code is being >> dictated by some abstract ideology instead of technic= al reasons?
>>&nb= sp;
>> A
>> ----------------= --------------------------------------------------------
>= > *From:* Pete Batard <pet= e@akeo.ie>
>> *Sent:* Sunday, April 19, 2020 9:1= 9 AM
>> *To:* Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj= -Mahmoud 
&= gt;> <samer@elha= jmahmoud.com>; devel@edk2.groups.io <devel@edk2.groups.io>
>= > *Cc:* Leif Lindholm <leif@nuviainc.com>; Andrei Warkentin 
>> <awarkentin@vmware.com>
>&= gt; *Subject:* Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : 
>> Enab= le TFTP shell command
>> On 2020.04.19 14:33, Ard Biesh= euvel wrote:
>>> On 4/19/20 3:04 PM, Samer El-Haj-Ma= hmoud wrote:
>>>> Fix an ASSERT with the TFTP dyn= amic Shell command on the
>>>> RPi3 and RPi4 when= running DEBUG builds. Also, enable the
>>>> comm= and by default for all builds.
>>>>
>>> 
>>> Fixing the ASSERT is fine but I am reluctant to enable = this by default.
>> 
>> I'm going to second this.
>> 
>> To answer a question Samer was asking elsewhere, this is ac= tually part
>> of the reason why TFTP is not enabled in= the DEBUG builds we produce at
>> ht= tps://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.co= m%2Fpftf%2FRPi4&amp;data=3D02%7C01%7Cawarkentin%40vmware.com%7Cff25433f= 108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63722= 9246665197560&amp;sdata=3DrgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3= D&amp;reserved=3D0 
> >> (See build_firmware.sh), the reasoning
&= gt;> being that if someone encounters an issue with RELEASE and we ask t= hem
>> to troubleshoot with the DEBUG artifact, we want= to eliminate potential
>> troublemakers when they try = that.
>> 
>>> It is a non-standard hack that ARM contribu= ted in the past, and is not 
>>> covered by the EFI of Shell specifications. = If RPi4 is intended to be a 
>>> showcase for UEFI on ARM done right, we shou= ld not enable this at all.
>> 
>> Here I have to point out t= hat RPi4 becoming a showcase because we intend
>> to is= not what we are pursuing (because if it was a matter of "willing"
>> a showcase into existence, we would have picked a platform = with a lot
>> less quirks, more comprehensive documenta= tion, and so on).
>> 
>> Instead, we estimate that due to it= s price point and widespread
>> availability, it *is* g= oing to become a de facto showcase, whether
>> everybod= y likes it or not. And that is the reason we want to treat is as
>> a showcase where possible.
>> 
>> Regards,>> >> /Pete
>> 
> 
> 
>&nb= sp;
> 


--Apple-Mail=_1C2DE312-9F2E-4F08-8FF2-11CB487B08D3--