Re: Un-sucking EINVAL

On Wed, 21 May 2025 at 10:08, Warner Losh <imp@bsdimp.com> wrote:

The other way to report this would be via something new. There's no new
> register we can report this on in most architectures: they all have
> proscribed
> roles that we can't change (or that would be unwise for use to change).
> There's
> some temp registers on some architectures we might get away with using
> since their values aren't preserved across system call boundaries. But if
> we
> can't use a register, then we'd have to make a note of it in the
> threads structure
> so we could add a. system call to return it, which does start to get messy
> since
> the thread structure is somewhat optimized for size and fitting in cache
> lines.
> And if we're going to grow the thread structure, we'd want to maybe just
> store the string (though memory management issues popup)....
>

Having tinkered with this in our ${WORK} OS, it's not /too/ bad, as long as
we'd do a couple things:

* make it a syscall for now, yeah with all of the thread storage stuff you
mentioned;
* make fetching it a library function; (so you can change the underlying
representation);
* (yeah rust/go/etc language bindings will get angry at you, but that's
gonna happen regardless so just be comfortable with that);
* make decoding it a library function, not macros;
* make getting/formatting the strings a library function, not a C array of
strings;
* .. and since the errors themselves can encode info IN the error, have it
return a string that you MUST free(), so it can have args substituted
  into the string, so developers don't have to go and parse the string
itself and re-invent turning the new error code(s) into a useful string;
* make sure that there's always a mapping from the new error return to an
existing errno, so code CAN operate by just checking errno.

What was SUPER fun was learning that system programmers wanted the detailed
errors for logging/telemetry/debugging,
but NOT for actual code flow. They ended up wanting the top level bucket to
be "how should I treat this error", which
mostly mapped OK to errnos, and then the detailed error code for
diagnostics. It almost felt like SMTP/NNTP/HTTP error
code hierarchies too :-)



-adrian


> In short, I'd love to widen the interface, but there's a number of
> practical
> issues in the way.
>
> Warner
>
>