Broken build on OpenBSD

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210301/08fcb7b8/attachment.sig>