Hey Andrew,
Thank you a lot. One thing I noticed is that part of the quote I did not
see on the list before, so I marked it below.
Best regards,
Marvin
On 08.04.21 00:10, Andrew Fish wrote:
Some of use also sit on the UEFI standards committees so getting
changes into the specification is possible with in constraints of what
the spec committees find acceptable.
Thanks,
Andrew Fish
On Apr 7, 2021, at 3:02 PM, Andrew Fish via groups.io
<http://groups.io> <afish=apple....@groups.io
<mailto:afish=apple....@groups.io>> wrote:
On Apr 7, 2021, at 2:50 PM, Michael Brown <mc...@ipxe.org
<mailto:mc...@ipxe.org>> wrote:
On 07/04/2021 22:31, Marvin Häuser wrote:
Sorry, but I do not see why this would be the case. In fact the
solution is (temporary) co-existence, as already is the case with
InstallProtocolInterface() and InstallMultipleProtocolInterfaces()
InstallMultipleProtocolInterfaces() is not a breaking change: the
existence of InstallMultipleProtocolInterfaces() does not require
any change to the way that InstallProtocolInterface() is implemented
or consumed.
Code written before the invention of
InstallMultipleProtocolInterfaces() will still work now, with no
modifications required.
the new APIs would be a superset of the old ones, latter can be
implemented with former, as also previously done (*2_PROTOCOL
instances and shims in e.g. EdkCompatibilityPkg). In some cases,
the original protocol interfaces were actually deprecated
successfully from the EDK II code base. I would probably offer PCDs
to disable the expose of the old APIs, so platforms with little
need for backwards-compatibility and more focus on security can
tighten the constraints as they see fit. Considering the shimmed
interfaces for the old protocols/PPIs/... can be implemented on top
of the new public API, and the public API must not change, this
code would be practically maintenance-free too in my opinion.
You have to remember that UEFI is not a monolithic codebase with a
single maintaining organisation. Implementing a *2_PROTOCOL and
deprecating the original just causes pain for all the code in the
world that is maintained outside of the EDK2 repository, since that
code now has to support *both* the old and new protocols.
As for your example, I do not believe what is described is "broken".
To avoid distraction from that specific example: have a different
example. The EFI_USB_IO_PROTOCOL is fundamentally broken from the
perspective of implementing a network device driver, since there is
simply no way to enqueue a receive buffer that will wait for the
next available packet. But this won't get fixed, because it can't
get fixed without breaking API compatibility.
(Incidentally, I've observed UEFI software in the wild (from Insyde)
that works around these UEFI USB specification flaws by having all
of the USB drivers bind to private protocols in addition to
EFI_USB_IO_PROTOCOL, resulting in device drivers that point-blank
fail to work with a standards-conformant UEFI USB host controller
driver.)
Don't get me wrong: I *am* in favour of improving the security of
EDK2, and a formally verified loader is potentially useful for that.
But I could only consider it a good idea if it can be done without
making breaking API changes for which I know I will personally have
to maintain workarounds for the next ten years.
Well it is just software at the end of the day. We could always wrap
any Industry Standard API (PPI, Protocol, etc) in a library function
and let people chose backward compatibility vs better security. The
Library Class would be owned by the edk2 Open Source project so we
have more control over it.
The general UEFI (and UEFI PI) is we mostly add new things, and don’t
depreciated things to maintain compatibility. So for example you can
add a new Protocol to a handle so you have V1 and V2 of a protocol on
the same handle. An example of this is SimpleTextIn and
SimpleTextInEx. SimpleTextIn was modeled on the LCD of a serial
terminal (our server roots) so it did not expose modifier keys, or
have an easy way to implement snag keys so that is why SimpleTextInEx
got added for the new functional.
Thanks,
Andrew Fish
^ Here; +1
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73829): https://edk2.groups.io/g/devel/message/73829
Mute This Topic: https://groups.io/mt/81853302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
