Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command

["Andrei Warkentin" <awarkentin@vmware.com>]

[-- Attachment #1: Type: text/plain, Size: 6954 bytes --]

Stepping 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?

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 <awarkentin=vmware.com@groups.io>
Sent: Sunday, April 19, 2020 3:42 PM
To: Pete Batard <pete@akeo.ie>; 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/RaspberryPi : 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 contract 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 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, complexity, etc).

A
________________________________
From: Pete Batard <pete@akeo.ie>
Sent: Sunday, April 19, 2020 3:24 PM
To: Andrei Warkentin <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/RaspberryPi : 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 <devel@edk2.groups.io> on behalf of Pete
> Batard via groups.io <pete=akeo.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>; 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 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" or
>> 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 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?
>>
>> 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@edk2.groups.io>
>> *Cc:* Leif Lindholm <leif@nuviainc.com>; Andrei Warkentin
>> <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
>>>> 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=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4&amp;data=02%7C01%7Cawarkentin%40vmware.com%7Cff25433f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229246665197560&amp;sdata=rgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4&data=02%7C01%7Cawarkentin%40vmware.com%7Ccdee787f93404c06347908d7e4a224c2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229257370688870&sdata=HMeXi%2FIPSgNEcMZkoVAOjfFob9KVafL8tffomlyD7Ko%3D&reserved=0>
>
>> (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 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 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 as
>> a showcase where possible.
>>
>> Regards,
>>
>> /Pete
>>
>
>
>
>



[-- Attachment #2: Type: text/html, Size: 11699 bytes --]