On Fri, Feb 26, 2021 at 01:01:58PM -0600, Alex G. wrote:
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.
There's two different problems here. The first problem is that for user space tools (which is what this problem report is about), there's very well understood conventions and we need to follow that. We in fact (and this is hard) need to follow a slightly more reduced set of possible values than we might otherwise as some BSDs do not have all POSIX.1-2001 values _and_ it needs to be consistent with the general understanding of the values too.
The second problem is that we need to be internally consistent about what we use for error return codes, and what they mean, and doc/driver-model/design.rst needs an update. DM is the thing that ties all of the various subsystems together and leads to consistency between various similar functions.
Things get tricky when we (for generally good reason) share the same code between both cases.