Sorry, I accidentally removed an inline comment when sending.
Best regards,
Marvin
On 08.04.21 11:41, Marvin Häuser wrote:
Well, I assume this is a misunderstanding. I understood your usage of
"workaround" to be supporting both *_PROTOCOL and *2_PROTOCOL
instances. Yes, backwards-compatibility will be broken in the sense
that the new interface will not be compatible with the old interface.
No, backwards-compatibility will not be broken in the sense that the
old API is absent or malfunctioning. As I *have* said, I imagine there
to be an option (default true) to expose both variants. With default
settings, I want the loader to be at the very least mostly
plug-'n'-play with existing platform drivers and OS loaders from the
real world. "Mostly" can be clarified further once we have a detailed
plan on the changes (and responses to e.g. malformed binary issues
with iPXE and GNU-EFI).
Best regards,
Marvin
On 08.04.21 11:26, Michael Brown wrote:
On 08/04/2021 09:53, Marvin Häuser wrote:
On 07.04.21 23:50, Michael Brown wrote:
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 same is true for the *2_PROTOCOL instances, I do not see how you
distinct between them. Could you elaborate, please?
The distinction is very straightforward. If you plan to *remove*
support for the older protocols, then you by definition place a
burden on all externally maintained code to support both protocols.
If the older protocol will continue to be supported then no such
burden is created.
This is why I am asking you if your proposed changes require
*breaking* backwards compatibility. You still haven't answered this
key question.
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.
I am aware, but actually it's not far from it nowadays. In contrast
to the days of Aptio IV, I believe all big vendors maintain forks of
EDK II. I know the fork nature taints the issue, but also see last
quote comment.
This is empirically not true. Buy a selection of devices in the
wild, and you'll find a huge amount of non-EDK2 code on them.
It is not about "how much" is EDK II code, but that it is the core. We
are talking about things like the dispatcher, I have not ever seen it
modified "lately" (Gigabyte modded AMI CORE_PEI and CORE_DXE with their
SIO code in Z77, but you get the idea...). I am very well aware of
issues with "user-facing" things such as input.
I would be extremely happy if every vendor just used the EDK2 code:
it would make my life a lot easier. But it's not what happens in the
real world.
I see that there is no EFI_USB_IO2_PROTOCOL instance to argue by.
Yet there are EFI_BLOCK_IO2_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL.
Former, in my opinion, close in nature to your your example, and
latter close to the nature on what I plan to propose. Sorry, but I
do not see how what I suggest has not been done multiple times in
the past already.
Please also look at it from an angle of trust. How can I trust the
"secure" advertisements of UEFI / EDK II when the specification
*dictates* the usage of intrinsically insecure APIs?
The consequence for security-critical situations would be to
necessarily abandon UEFI and come up with a new design. In who's
interest is this?
Again, we return to the question that you have not yet answered: do
your proposed changes require breaking backwards compatibility?
Please do answer this question: if you're *not* proposing to break
the platform in a way that would prevent older binaries from working
without modification, then we have no disagreement! :)
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.
Sorry, but you seem to have missed my points regarding these
concerns, at least you did not address them I believe. I don't know
why you need to (actively) maintain workarounds for APIs external
code has no reason to use, especially when the legacy implementation
would quite literally be a wrapper function.
<same comment as above>
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73837): https://edk2.groups.io/g/devel/message/73837
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]
-=-=-=-=-=-=-=-=-=-=-=-
