Broken build on OpenBSD

[Alex G.]

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