From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.1138.1587365120493064477 for ; Sun, 19 Apr 2020 23:45:20 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9FD99C14; Sun, 19 Apr 2020 23:45:19 -0700 (PDT) Received: from [192.168.1.81] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AEE153F6CF; Sun, 19 Apr 2020 23:45:18 -0700 (PDT) Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command To: awarkentin@vmware.com, Andrew Fish , "devel@edk2.groups.io" Cc: Pete Batard , Samer El-Haj-Mahmoud , Leif Lindholm 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> From: "Ard Biesheuvel" Message-ID: <10bee111-6628-e111-1057-9608bbd31521@arm.com> Date: Mon, 20 Apr 2020 08:45:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/20/20 4:41 AM, awarkentin@vmware.com wrote: > Hi Andrew, >=20 > This particular issue revolves around enabling a feature by default in=20 > the DSC for Pi 3/4 platforms - the TFTP Shell command. Clearly, enablin= g=20 > this for Pi bears no effect on other Tiano platforms. So far I've heard= =20 > something about the TFTP code being somehow bad, but what does that hav= e=20 > to do with the Pi platform using it? If it's bad, delete it from Tiano.= =20 > Or rewrite it. >=20 The TFTP command can be included by a -D option on the build command=20 line, but I am opposing to enabling it by default. The reason for this=20 is that we have been trying to push back on custom vendor tools to do=20 firmware upgrades and other things from the shell, and instead, use=20 capsule update. I really don't get what the drama is all about, given that the TFTP=20 command is only a -D option away when you want it, and we don't=20 distribute binary builds from edk2-platforms anyway. > .../last/ time we got into a spat about the value of revving the Pi ACP= I=20 > to 6.3 (the ACPI support we contributed in the first place). So that=20 > patch just got ignored. Not even sure what to do about that one... >=20 I rejected ACPI 6.3 table upgrades because, in their current form, the=20 only thing they achieve is losing the ability to boot an OS that=20 predates ACPI 6.3. Every piece of the platform currently being described=20 via ACPI can be described using 5.1 tables. ACPI 6.3 tables are not 'better' or 'more current' than 5.1 ones. ACPI=20 6.3 tables should be used if/when they are needed, and not before. > I don't know, the maintainers may in fact be in perfect agreement (I=20 > certainly do not know) - but certainly at odds with actual developers.=20 > So, there appears to be a problem with the way edk2-platforms is run. O= r=20 > at the very least, I don't understand why it's run the way it's run. >=20 > The RPi3/4 support is developed by a group of folks=20 > (https://rpi4-uefi.dev, https://github.com/pftf). These folks (from Arm= ,=20 > from VMware, or unaffiliated) all follow their own goals, with some=20 > alignment, but there's overall consensus that working upstream is A Goo= d=20 > Thing and is worth the effort. We loosely=A0 coordinate with each other= =20 > (Discord, have a bug tracker, etc). However, it seems that every patch=20 > we propose, to a code base that we largely wrote and chose to upstream=20 > into edk2-platforms, gets put under the microscope. That would be fair=20 > and square when we're talking about changes to shared components, or=20 > code that for technical reasons (quality or design) does not fit the=20 > implementation/design goals of Tiano. However, what ends up happening i= s=20 > _maintainers_ taking arbitrary decisions, contrary to the community of=20 > developers behind the port. As a final say. I don't mean an abstract=20 > mute community of developers. I mean the folks that specifically do all= =20 > development today for Tiano on Pi platforms. We have no control. We hav= e=20 > no say. Maintainers are certainly developers, and may have a stake and=20 > interest in the code being reviewed, but at the end of the day they are= =20 > maintainers - they need to abstract away and agree to disagree on=20 > matters that are subjective and opinion-based. >=20 It is funny how it depends on the context whether I am considered just a=20 maintainer or one of the developers. Please don't misrepresent my=20 involvement as sitting passively on the receiving end of a patch=20 pipeline: I wrote the original barebones 64-bit port for Raspberry Pi in=20 the first place, and I am [somewhat] active in the development community=20 that you started around it. > Why are maintainers making these calls? We brought these platforms into= =20 > your garden because we were sold on the idea. Let us water them and tak= e=20 > care of them together. Instead, everything we do gets frisked with a=20 > strip search. We have to spend our time constantly proving the value of= =20 > our work instead of using that very little valuable time we have to=20 > actually move the Pi support forward. >=20 Upstreaming code is a negotiation (via review) where the contributors=20 and the maintainers converge on the terms under which the maintainers=20 are willing to take charge of the code, and assume the responsibility=20 that it will remain current and in working order going forward. > The outcomes are pretty serious. If you ask folks in the Arm community,= =20 > they'll tell you "upstream first", and specifically cite lack of=20 > firmware being upstreamed as being a serious problem. However, the way=20 > edk2-platforms is structured, that goal is literally unobtainable=20 > because edk2-platforms development doesn't scale, as all code gets=20 > funneled through the few maintainers. I mean, why would anyone choose t= o=20 > upstream to edk2-platforms? For the lack of positive reinforcement? For= =20 > the tedious process with no light at the end of the tunnel? It turns=20 > developers away. It makes folks feel unvalued and disenfranchised. You=20 > get to burn the midnight oil - pro bono - into something only to have=20 > others tell you that you should have done something else or just get=20 > your proposals ignored. It's not really a community - our choices, our=20 > code and our desire to CONTRIBUTE and BE RESPONSIBLE for a proper=20 > polished UEFI experience on the Raspberry Pi are worth absolutely=20 > nothing here. >=20 Again, can we please cut the drama? I have objected to a) replacing ACPI 5.1 tables with ACPI 6.3 tables for a piece of=20 hardware that is 100% covered by the ACPI 5.1 spec b) enabling TFTP by default Beyond that, I don't remember any exchanges where we did not converge in=20 the end on something we were all happy with. > Why does a maintainer have any say over platform-specific code, where=20 > there is developer consensus on the trajectory and there are no=20 > over-arching technical concerns? Why can't individual platforms have=20 > their own maintainers? >=20 If you think 'developer consensus' should be sufficient justification to=20 take any change without scrutiny, I think you are looking for a hosting=20 platform, not an upstream open source project. Individual platforms can have their own maintainers. However,=20 maintainership is a role you typically have to earn in a community. What gets lost in the debate is the fact that we are all on the same=20 side here: we all want the best possible support for Raspberry Pi 3/4 to=20 be available in Tianocore. Escalating a silly difference of opinion such=20 as the TFTP issue to these levels only distracts from that. I have stated before that I *really* like the Raspberry Pi port for its=20 polish and looks [none of which are my accomplishments], but the fact=20 (intentional or not) that it may become an example followed by others=20 when creating EDK2 ports for ARM means that I have a responsibility to=20 my employer *and* the community to ensure that it is a good=20 approximation of what state of art means for ARM platforms. So better integration with the UEFI driver model for the onboard=20 peripherals is high on my list, as well as moving away from PrePi, so we=20 can start thinking about things like Capsule Update and measured boot=20 (if you have the hardware). I am not saying this is your responsibility (or anyone else's) but=20 simply that the port is not finished, and so we haven't entered the=20 phase yet where we're just dotting Is and crossing Ts. So if enabling=20 TFTP support makes it easier to use a board specific hack to update your=20 firmware, it shouldn't be enabled by default, and distract from the fact=20 that we are still lacking support for UpdateCapsule(). --=20 Ard.