On 2/25/21 1:31 PM, Simon Glass wrote:
Hi Alex,
To the extent that it is unconventional, that reflects the decision to avoid adding U-Boot-specific error numbers and perhaps also to avoid having a different error number for each possible failure in U-Boot.
The set of errno codes is much smaller than the set of possible failures. It is objectively impossible to map the set of possible failures onto the set of errno codes. And that's why I think this decision is wrong.
The following arguments are subjective:
Compared to TF-A and OP-TEE, I find u-boot sources more difficult to work with. One of the reasons is that different parts have different idiosyncrasies. TF-A and OP-TEE are bad in their own ways, but they are at the very least, consistent wrt conventions of the C language. Now we're talking about every u-boot function potentially having its own semantics. This is going from bad to worse. And now the code is returning error codes that don't even make sense in context.
What you're describing (not quoted in this reply) is a mechanism to allow users to handle failures. We first need to define user and how the user interfaces with the software product. For example, is someone who presses the power button also expected to resolve storage media corruption? Only then can we spec out the requirements for this mechanism. We somehow have the solution to a problem that isn't properly defined yet.
This is a textbook example of when all you have is a hammer, everything looks like a nail.
Alex