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....@groups.io> Sent: Sunday, April 19, 2020 3:42 PM To: Pete Batard <p...@akeo.ie>; devel@edk2.groups.io <devel@edk2.groups.io>; Ard Biesheuvel <ard.biesheu...@arm.com>; Samer El-Haj-Mahmoud <sa...@elhajmahmoud.com> Cc: Leif Lindholm <l...@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 <p...@akeo.ie> Sent: Sunday, April 19, 2020 3:24 PM To: Andrei Warkentin <awarken...@vmware.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Ard Biesheuvel <ard.biesheu...@arm.com>; Samer El-Haj-Mahmoud <sa...@elhajmahmoud.com> Cc: Leif Lindholm <l...@nuviainc.com> Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command On 2020.04.19 21:21, awarken...@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...@groups.io> > *Sent:* Sunday, April 19, 2020 3:06 PM > *To:* devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warkentin > <awarken...@vmware.com>; Ard Biesheuvel <ard.biesheu...@arm.com>; Samer > El-Haj-Mahmoud <sa...@elhajmahmoud.com> > *Cc:* Leif Lindholm <l...@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 <p...@akeo.ie> >> *Sent:* Sunday, April 19, 2020 9:19 AM >> *To:* Ard Biesheuvel <ard.biesheu...@arm.com>; Samer El-Haj-Mahmoud >> <sa...@elhajmahmoud.com>; devel@edk2.groups.io <devel@edk2.groups.io> >> *Cc:* Leif Lindholm <l...@nuviainc.com>; Andrei Warkentin >> <awarken...@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&data=02%7C01%7Cawarkentin%40vmware.com%7Cff25433f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229246665197560&sdata=rgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3D&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 >> > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#57580): https://edk2.groups.io/g/devel/message/57580 Mute This Topic: https://groups.io/mt/73127191/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
