From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.107.236.54]) by mx.groups.io with SMTP id smtpd.web12.6174.1587328933596076530 for ; Sun, 19 Apr 2020 13:42:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=LFqderTS; spf=pass (domain: vmware.com, ip: 40.107.236.54, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J6enZorSfe4b2kZGApkPDELnXDUjGFCs36u7yo8CUEtOxzP0l4dRviCSquSBwxioldfKLta0o8OXh7uwb0hKf6Rk3rPq9sXS7pTNgyQ08/Fp2v+KNbK7seWHRIZ1t7xlOK9/X5clGL2gInepo0iRHDUIUU4N2p3fpJsTy+Ldh0hfYBYWH1fiNSYINQxXa78vUq0uNc3H6oaEJ7cQtp7Zlyr4xM0sdVrooMbfo8bfCAon/mIZwnnSU+Z/qU45ui7LTdp3rLMCxLP9eEqZ8+BH+wrTswNCv8AsI038PORtYnK6LQ/E0CPdke1oVPPYjl9G7BOgcNYd+U3sgNb6jeD+9A== 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=ZcTf+Zl5fnnm/8/N8cqHk0b7ZOQSSB8MnbmkC5R6KJ0=; b=ORLN1Y0khYadJ3VUwSXmPv1sPbaSLs9FTvrbgQghpm1erhb3RczsoZyTTEEDYhTGnx1BwoivHDmOASK7ALsYerXdj6ojULa+bwQF312xYXP/jRJIDXHLgF/WGpbaOezItpgnrt8yq+3nsD4RHKn3MQGtJVTsuOGk5WeVu2Qo0KY4kctvG5GgXUn114DbLdkp/lwo7bLqSUfHJ0XZDxXak3oA37ChBJIJDR67G9Vp5i2lqSWK7sn8HDAPkufnvjJ4COlM9FgYkYkyr687xDKGQTGzXm8pB1/kfIUwydG3AHZpNtStqKcou3CqjK/BjujG2jfvUewlK/0LtfRKpcES6Q== 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=ZcTf+Zl5fnnm/8/N8cqHk0b7ZOQSSB8MnbmkC5R6KJ0=; b=LFqderTSnYgJcKJjb/Yjvp0rHQNSJtvRYqAKsKkFcBDGHtmDMn1StSscFpOOwKTpAB9+oLtkwDdn26eFoAt5xJF7bRsjSr9O9Viv+a3Bdn8ymRGAtSrpAiXhq8m/dfps6IXHtksM52JRWW21DOHFsHlzehJyQbXVYJt8b+jTFKY= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB3362.namprd05.prod.outlook.com (2603:10b6:405:42::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Sun, 19 Apr 2020 20:42:11 +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 20:42:11 +0000 From: "Andrei Warkentin" 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/RaspberryPi : Enable TFTP shell command Thread-Topic: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Index: AQHWFksLVB8KW5eI1E6krRdTNHmDgaiAcbcAgAAM2gCAAFvq3oAABP0AgAAEA+qAAADzgIAAAwAS Date: Sun, 19 Apr 2020 20:42:11 +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> In-Reply-To: <2046f801-45c2-f591-fdf8-18e2edb093d3@akeo.ie> 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: d57bdb33-ca6c-4de9-c1f1-08d7e4a222a7 x-ms-traffictypediagnostic: BN6PR05MB3362: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; 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:(4636009)(376002)(136003)(366004)(346002)(39860400002)(396003)(8936002)(66556008)(9686003)(64756008)(45080400002)(110136005)(478600001)(76116006)(8676002)(66946007)(66446008)(66476007)(966005)(316002)(81156014)(4326008)(52536014)(7696005)(33656002)(186003)(71200400001)(86362001)(26005)(6506007)(53546011)(2906002)(5660300002)(19627405001)(55016002);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: E3QdYvWHZAcVwMpxp1R/gQGGsJxYWEqhrFyWq+yqOYI2YI1V2hGkhbXdNo0wxuMVagHDBqlyPKDzHg+SKl5nDSYSujwd9JhMj2GjTeYIArG62HaqtO0pnwaahXJ9oH5tURT9xiBAVYVzNtEBV+ZhuFRSQMJ3hUx59Z349K6h6a/VqM5xtzIgl1jExQZLGh8Ig9QcN97CRcTB+Xc8EpKdbk+9VHJoq7OyeJCfOZ3IZ2LcYveD4h2CVs2WNvBPvQtPked28CZKE5AvV8TNXwTgs/ngfm3AX0csYYcAq8Ot2KeQZSHgjHRvvfJ5X1J9u8g0T0w/eVbF4eAHq6aQQAt6atHfr+lUmWVj2TscDzzY1PFGhXf5xEA1hXDFg5N3WNpZlXyKU332EqBI4XVyEoAuZHPmk7zxr70xJ8l9vxbvpNBg9BRWPoqLuWZ273Fx8JxdrMaK/4/HIOWIFTg/7a3ciPgTJTpaGztAiYxM3WTGqZX3kaoNOIZocnthss+Hrmb8Mhp71mipdJMloF0KkcjBeg== x-ms-exchange-antispam-messagedata: 1CyFEsy/cMZC4eU7TeC9j6lIYTzlz0MBDNR1cZmCZ/ecy7AyetJJuOZotoGC0m+sknFVe6venV9ubtie8oyqn2N3G4sThh6sJOLfJwWRtqJxO8xzcjy3/XirfH4dxpWwiFOX/9hIWVKUoPyNZJ4utA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: d57bdb33-ca6c-4de9-c1f1-08d7e4a222a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 20:42:11.1729 (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: dBMD6oMT0h3kM9krEnEraLKV0f4oxI8bI2f6u7AkcRBCck08eIbqh1f02KORYuZevJO+oI66PGRjJ/gmAz3hFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3362 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB3411195F04F75E4040F689AEB9D70BN6PR05MB3411namp_" --_000_BN6PR05MB3411195F04F75E4040F689AEB9D70BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's part of Tiano, no? We didn't develop it. Yet I see it being used in ma= ny Tiano-derived UEFI implementations in the Arm world. I don't see a contr= act 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 >> > > >=20 > --_000_BN6PR05MB3411195F04F75E4040F689AEB9D70BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 <pete= @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 wrote:=
> 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_BN6PR05MB3411195F04F75E4040F689AEB9D70BN6PR05MB3411namp_--