From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (NAM12-DM6-obe.outbound.protection.outlook.com [40.107.243.79]) by mx.groups.io with SMTP id smtpd.web10.9172.1587340236883610799 for ; Sun, 19 Apr 2020 16:50:37 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=RAD19/u+; spf=pass (domain: vmware.com, ip: 40.107.243.79, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SV/67WuqLfpN4LzGmbkUPNtv1pcw8pDTms+RbipIAE0zNIJseHPC4mGoAjGvOYXb6pR0HqdYBruB+xjI/qEkOfhWSNLaQZHMkB5BbTJTd4qKSZHFDu78W/17VMPIAPfGQR/jU/HMXriolphyFe7Wx3y2jJJWZb9yo+OwhO1SU0sayMlNeJm4mOrH8kxkZpb7uxXuZFRvP0OTkUSJ615h1lIoud2AwVvgpPOFlO+PVPIeMcQrc3lbUpnlXQFpGs+fwKLSktZU8MFDD0v/LwojUg0egexISkZzJtuazuykq1vDx5z0gBfCSBBrC79/cWvABZiMYcaHH87HHDkvQXuTxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OaaXJDyEPF3YkHGVU/DPRK+pR5aSKFf1ubG8RGuxoRI=; b=WO4hdgpj4/L1D3nEec9bZmxZtDKZ6toQN/2RWJc1gXeRonR1s45pE64mZ7jmaQn0ah3bz9DPhbIQiu8SZHqgykp3aUT0fecNvF6aIBbNr7uKMr19LCBWOMHzG1PixN0KFNZcDph4TodovwTyKW7BegOIfu4vwaTN1zdO77He0InTLQVbQnzN4xGeBpXmap4XHqhTkh77DKacDGHaJ1e/beQ8ND+x68YOtwlrt+w6gxGTmzXdWTBGg5AWT7b7EgH8yqGfozup1AVKeCVlTNDCCcyO1wsdb+h6lQ/el+bgfKXZiS2/0XLHZPKeuySJjoDlRP5xKdQbJ0f/tXFtbfvfmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OaaXJDyEPF3YkHGVU/DPRK+pR5aSKFf1ubG8RGuxoRI=; b=RAD19/u+C0osQQ55pg1M6IWZF9hSyWBbnRzTtXOvUiSwG/mQ7b1Pk9C7gKYOdSp6DBm08mlPoGL0LtysA7WBHTqs+0QZvexrKEJ8kAi7rHfaP3TSsb35SIrNSyPcmjiGm0M3aQLnHrdKKTUbyNU78UldiyrK9o8WlMpscMto/tA= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB3587.namprd05.prod.outlook.com (2603:10b6:405:40::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.18; Sun, 19 Apr 2020 23:50:33 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84%5]) with mapi id 15.20.2921.027; Sun, 19 Apr 2020 23:50:33 +0000 From: "Andrei Warkentin" To: Pete Batard , "devel@edk2.groups.io" , Ard Biesheuvel , Samer El-Haj-Mahmoud , Andrei Warkentin CC: Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Topic: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Index: AQHWFksLVB8KW5eI1E6krRdTNHmDgaiAcbcAgAAM2gCAAFvq3oAABP0AgAAEA+qAAADzgIAAAwASgAA16E0= Date: Sun, 19 Apr 2020 23:50:33 +0000 Message-ID: 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> In-Reply-To: <160753416257B0CA.29096@groups.io> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=awarkentin@vmware.com; x-originating-ip: [98.214.99.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2502d1b-d007-4597-2833-08d7e4bc7362 x-ms-traffictypediagnostic: BN6PR05MB3587:|BN6PR05MB3587: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10009020)(4636009)(376002)(136003)(396003)(39860400002)(366004)(346002)(110136005)(76116006)(55016002)(71200400001)(86362001)(9686003)(4326008)(316002)(186003)(66946007)(66446008)(8676002)(64756008)(66556008)(81156014)(6506007)(66476007)(26005)(19627405001)(2906002)(7696005)(76236002)(5660300002)(45080400002)(478600001)(52536014)(966005)(8936002)(53546011)(33656002);DIR:OUT;SFP:1101; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +wjJ6z1eAo5um2Kjg4GnO5olCZVfeqduyFaGHbq2NLXePzzjejesymZof9AGuyT4dtYAmuWwJ0phUqzZNWBl8Ah/biIzFPL/VFOC4vLV9UXI6Lhc5T7gcSdak96HftaWBt1cFqTL5M7J2AuQn+bXS46sMTPtadahudUqzB95MhJRN3DT9vn7MsOCMx4Rvr58hwDDAkNqlA0rzdHnaon4A/Yntewzp7/NY0TwxLR83g3Y/1masRqutKhI7dErAQ2V4aMBNNjHJEFJEj7RxdZO09+c23yoNoBSkGhm9dNW4a508cJs8QQpDHD0WoGcqecf3MVmT7wDkOYtIImcpT0a0cprVtoWRd0+4X5g2gVRb5u1hrkqCT9kdTraoSIur3iFwjuc7xA0EAOBBe2siIHlpDeRFc/awg/y4DHRSp1REvydEqU0yZpgdja/eltbtt7fbehY+CAUnB8/i8ReZZaiT4gUNZM5gHretxxhTN6LXdAUkr6zASlAJW383Dc2aJLFj+EhdikU6+2tHeyPfw1k+Q== x-ms-exchange-antispam-messagedata: jngxvuaOImO/5NKtlP3LFI62kaZ2Dhk/yTe7/H8FE20znjPL5uYp7x9zMYeXJO4vGdMOmQ0Sy7mcFepZpS70d2UyiTRagUJ+28rMw+De/y9s/TCohIbRCqYKwAK2gvqnHoYL02NuHkDl+gSNJ7T5sQ== MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2502d1b-d007-4597-2833-08d7e4bc7362 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 23:50:33.5892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3KoCkyJM+FsgZ1fCLxz1r54TBhdRj7K81klEFRln9lyP6lcJCsQb+ipVN1w38iguwXSUWvxk7Hdww7GJzz9JZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3587 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB34114A86BCA73BB714F2C632B9D70BN6PR05MB3411namp_" --_000_BN6PR05MB34114A86BCA73BB714F2C632B9D70BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stepping back, can we do a roll call among stakeholders so we start treatin= g 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? How many points do folks thing we need for a merge? I'd say +2. A ________________________________ From: devel@edk2.groups.io on behalf of Andrei Wark= entin via groups.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/Raspberry= Pi : Enable TFTP shell command It's part of Tiano, no? We didn't develop it. Yet I see it being used in m= any Tiano-derived UEFI implementations in the Arm world. I don't see a cont= ract anywhere that all Tiano implementations ought to avoid components that= don't fit the UEFI/PI/Shell specs. Can someone point me to such a contract= ? We're entering the "victimless crime" territory here, and also violating t= he principle of least surprise. I do agree that DEBUG profile may choose a subset of configuration options= , for reasons such as sticking to a smaller configuration (for size, comple= xity, etc). A ________________________________ From: Pete Batard Sent: Sunday, April 19, 2020 3:24 PM To: Andrei Warkentin ; devel@edk2.groups.io ; Ard Biesheuvel ; Samer El-Haj-Mahm= oud Cc: Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Raspberry= Pi : Enable TFTP shell command On 2020.04.19 21:21, awarkentin@vmware.com wrote: > So if I understood correctly: > > * If a random person off the street builds edk2 - they don't get TFTP > command out of the box Yup. For the reasons that Ard pointed out (current TFTP being a non-standard hack that should be replaced by something more suitable... eventually). > * Our builds retain TFTP command Yup. > > Correct? > ------------------------------------------------------------------------ > *From:* devel@edk2.groups.io on behalf of Pete > Batard via groups.io > *Sent:* Sunday, April 19, 2020 3:06 PM > *To:* devel@edk2.groups.io ; Andrei Warkentin > ; Ard Biesheuvel ; Samer > El-Haj-Mahmoud > *Cc:* Leif Lindholm > *Subject:* Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] > Platform/RaspberryPi : Enable TFTP shell command > Andrei, > > In case this is your concern, please note that we are not removing TFTP > 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 wish)= . > > 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. > > 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 they > might wish for, and, even with the revised patch, TFTP will remain > enabled in our RELEASE binaries, exactly 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 >> we choose functionality? Functionality that's part of Tiano? The real >> world doesn't care about the TFTP command being an "unsupported hack" o= r >> not. So there's Tiano-specific code here. Big deal? To rephrase >> differently, why would either Pi 4 developers or Pi 4 UEFI users pay th= e >> cost of Tiano carrying code that somehow isn't "legit enough" to be ena= bled? >> >> I mean here we are again, where what goes into the code is being >> dictated by some abstract ideology instead of technical reasons? >> >> A >> -----------------------------------------------------------------------= - >> *From:* Pete Batard >> *Sent:* Sunday, April 19, 2020 9:19 AM >> *To:* Ard Biesheuvel ; Samer El-Haj-Mahmoud >> ; devel@edk2.groups.io >> *Cc:* Leif Lindholm ; Andrei Warkentin >> >> *Subject:* Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : >> 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. >>>> >>> >>> 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 actually part >> 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%2Fgit= hub.com%2Fpftf%2FRPi4&data=3D02%7C01%7Cawarkentin%40vmware.com%7Cff2543= 3f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637= 229246665197560&sdata=3DrgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3D&= amp;reserved=3D0 > >> (See build_firmware.sh), the reasoning >> being that if someone encounters an issue with RELEASE and we ask them >> to troubleshoot with the DEBUG artifact, we want to eliminate potential >> troublemakers when they try that. >> >>> It is a non-standard hack that ARM contributed 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 should not enable this at all. >> >> Here I have to point out that RPi4 becoming a showcase because we inten= d >> 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 documentation, and so on). >> >> 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 a= s >> a showcase where possible. >> >> Regards, >> >> /Pete >> > > > > --_000_BN6PR05MB34114A86BCA73BB714F2C632B9D70BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Stepping back, can we do a roll call among stakeholders so we start treati= ng contentious issues as a community?

So far:

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

Anyone else?

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 Warkentin via groups.io &= lt;awarkentin=3Dvmware.com@groups.io>
Sent: Sunday, April 19, 2020 3:42 PM
To: Pete Batard <pete@akeo.ie>; devel@edk2.groups.io <deve= l@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/Ra= spberryPi : Enable TFTP shell command
 
It's part of Tiano, no? We didn't develop it. Yet I see it being used in m= any Tiano-derived UEFI implementations in the Arm world. I don't see a cont= ract anywhere that all Tiano implementations ought to avoid components that= don't fit the UEFI/PI/Shell specs. Can someone point me to such a contract?

We're entering the "victimless crime" territory here, and also v= iolating the principle of least surprise.

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

A
From: Pete Batard <pe= te@akeo.ie>
Sent: Sunday, April 19, 2020 3:24 PM
To: Andrei Warkentin <awarkentin@vmware.com>; devel@edk2.grou= ps.io <devel@edk2.groups.io>; Ard Biesheuvel <ard.biesheuvel@arm.c= om>; Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Ra= spberryPi : Enable TFTP shell command
 
On 2020.04.19 21:21, awarkentin@vmware.com wrot= e:
> So if I understood correctly:
>
>   * If a random person off the street builds edk2 - they do= n't get TFTP
>     command out of the box

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

>   * Our builds retain TFTP command

Yup.

>
> Correct?
> ---------------------------------------------------------------------= ---
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf o= f 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 Warke= ntin
> <awarkentin@vmware.com>; 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/RaspberryPi : Enable TFTP shell command
> Andrei,
>
> In case this is your concern, please note that we are not removing TF= TP
> support at all, which is enabled for the RELEASE builds we produce an= d
> will remain so (and which anyone can enable with the macro if they wi= sh).
>
> All that will be changed by the updated proposal is that the current<= br> > DEBUG ASSERT will be fixed and TFTP support will remain optional, lik= e
> it is today.
>
> 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 t= hey
> might wish for, and, even with the revised patch, TFTP will remain > enabled in our RELEASE binaries, exactly 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 wo= uldn't
>> we choose functionality? Functionality that's part of Tiano? The = real
>> world doesn't care about the TFTP command being an "unsuppor= ted hack" or
>> not. So there's Tiano-specific code here. Big deal? To rephrase <= br> >> differently, why would either Pi 4 developers or Pi 4 UEFI users = pay the
>> cost of Tiano carrying code that somehow isn't "legit enough= " to be enabled?
>>
>> I mean here we are again, where what goes into the code is being =
>> dictated by some abstract ideology instead of technical reasons?<= br> >>
>> A
>> -----------------------------------------------------------------= -------
>> *From:* Pete Batard <pete@akeo.ie>
>> *Sent:* Sunday, April 19, 2020 9:19 AM
>> *To:* Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj= -Mahmoud
>> <samer@elhajmahmoud.com>; devel@edk2.groups.io <devel@ed= k2.groups.io>
>> *Cc:* Leif Lindholm <leif@nuviainc.com>; Andrei Warkentin <= br> >> <awarkentin@vmware.com>
>> *Subject:* Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi= :
>> 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<= br> >>>> RPi3 and RPi4 when running DEBUG builds. Also, enable the=
>>>> command by default for all builds.
>>>>
>>>
>>> Fixing the ASSERT is fine but I am reluctant to enable this b= y default.
>>
>> I'm going to second this.
>>
>> To answer a question Samer was asking elsewhere, this is actually= part
>> of the reason why TFTP is not enabled in the DEBUG builds we prod= uce at
>> https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fpftf%2FRPi4&amp;data=3D02%7C01%7Cawarkentin%40vmware.com%7Cff254= 33f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63= 7229246665197560&amp;sdata=3DrgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJG= g%3D&amp;reserved=3D0
>
>> (See build_firmware.sh), the reasoning
>> being that if someone encounters an issue with RELEASE and we ask= them
>> to troubleshoot with the DEBUG artifact, we want to eliminate pot= ential
>> troublemakers when they try that.
>>
>>> It is a non-standard hack that ARM contributed in the past, a= nd is not
>>> covered by the EFI of Shell specifications. If RPi4 is intend= ed to be a
>>> showcase for UEFI on ARM done right, we should not enable thi= s at all.
>>
>> Here I have to point out that RPi4 becoming a showcase because we= intend
>> to is not what we are pursuing (because if it was a matter of &qu= ot;willing"
>> a showcase into existence, we would have picked a platform with a= lot
>> less quirks, more comprehensive documentation, and so on).
>>
>> Instead, we estimate that due to its price point and widespread >> availability, it *is* going to become a de facto showcase, whethe= r
>> everybody likes it or not. And that is the reason we want to trea= t is as
>> a showcase where possible.
>>
>> Regards,
>>
>> /Pete
>>
>
>
>
>

--_000_BN6PR05MB34114A86BCA73BB714F2C632B9D70BN6PR05MB3411namp_--