Re: new errno ?

[Thor Lancelot Simon]

The DOMAIN and RANGE errno values are not really used outside
floating-point code, and are...conceptually appropriate...to
many other kinds of problems.

Thor

On Fri, Jul 06, 2018 at 03:59:12PM -0700, Jason Thorpe wrote:
> 
> 
> > On Jul 6, 2018, at 2:49 PM, Eitan Adler  wrote:
> > 
> > For those interested in some of the history:
> > https://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000791.html 
> > 
> 
> ...and the subsequent thread went just as I expected it might.  Sigh.
> 
> Anyway... in what situations is this absurd error code used in the 802.11 
> code?  EFAULT seems wrong because it means something very specific.  
> Actually, that brings me to a bigger point... rather than having a generic 
> error code for "lulz I could have panic'd here, heh", why not simply return 
> an error code appropriate for the situation that would have otherwise 
> resulted in calling panic()?  There are many to choose from :-)
> 
> -- thorpej
> 

-- 
  Thor Lancelot Simont...@panix.com
 "The two most common variations translate as follows:
illegitimi non carborundum = the unlawful are not silicon carbide
illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: new errno ?

[Robert Elz]

Date:Fri, 6 Jul 2018 13:46:42 -0600
From:Warner Losh 
Message-ID:  



  | Poul-Henning added it to differentiate between potentially valid but not in
  | this combo (EINVAL or EFAULT) and args that are clearly programming errors
  | (EDOOFUS), but in code that couldn't just panic.

I fail to understand the logic behind that.   What's more I think from the 
original (FreeBSD) thread, it is incorrect.,  That is, the argument was not
that the code could not panic (I find it very hard to even conceive of the
possibility of a case where it is possible to return an error to the user, but
a panic (in kernel) or abort() (in userlevel code) is not possible) but rather
that it was possible to not panic, and so that is the path that should be
taken.

Sorry, but that is just brain dead.

The situation where an internal programming inconsistency has been
detected is the one (perhaps the only) place where a panic (or abort)
is the right solution.   Then it happens, once, somewhere, someone works
out what caused it, fixes it, and it never happens again.

That's quite different than having perror() report "Programming Error"
which is likely to cause whatever user level programmer wrote the
code that got the error to scratch his.her head, try to figout out what
they did wrong, and either find a workaround (and believe they are
fixing their bug) or just give up ... and the error persists.

There's no question byt that unix does (always has) panic/crash far
too often, for things which would be better recovered from, or  reported
as wrrors to the user (various I/O errors, unplugging drives half way
through I/O, bad packet data ... ) which it would be really good to fix
(but much of that is HARD, and I am definitely not volunteering, I could
have worked on that kind of thing any time over the past 40+ years, and
never did ...)

But this one is different, this is "the system is screwed internally" (rof
whatever the "system" is in question) - simply aborting until the problem
gets fixed is the right solution.

kre

Re: new errno ?

[Warner Losh]

On Fri, Jul 6, 2018, 2:10 PM Greg Troxel  wrote:

>
> Phil Nelson  writes:
>
> > Hello,
> >
> > In working on the 802.11 refresh, I ran into a new errno code from
> FreeBSD:
> >
> > #define EDOOFUS 88  /* Programming error */
> >
> > Shall we add this one?  (Most likely with a different number since
> 88 is taken
> > in the NetBSD errno.h.)
> >
> >I could use EPROTO instead, but 
>
> My immediate reaction is not to add it. It's pretty clearly not in
> posix, unlikely to be added, and sounds unprofessional.


Poul-Henning added it to differentiate between potentially valid but not in
this combo (EINVAL or EFAULT) and args that are clearly programming errors
(EDOOFUS), but in code that couldn't just panic.

It seems like it would be used in cases where there is a KASSERT in the
> non-DIAGNOSTIC case.  I might just map it to EFAULT or EINVAL.
>

Not a terrible choice.

Warner

>

Re: new errno ?

[Jason Thorpe]

> On Jul 6, 2018, at 2:49 PM, Eitan Adler  wrote:
> 
> For those interested in some of the history:
> https://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000791.html 
> 

...and the subsequent thread went just as I expected it might.  Sigh.

Anyway... in what situations is this absurd error code used in the 802.11 code? 
 EFAULT seems wrong because it means something very specific.  Actually, that 
brings me to a bigger point... rather than having a generic error code for 
"lulz I could have panic'd here, heh", why not simply return an error code 
appropriate for the situation that would have otherwise resulted in calling 
panic()?  There are many to choose from :-)

-- thorpej