[TUHS] Tracing origins of errno names/numbers

[TUHS] Tracing origins of errno names/numbers

[Warren Toomey]

Hi all,
	PJ from groklaw.net has asked me to trace the origin of
the errno names and values in recent versions of Linux. Attached
is where I am up to. The columns are:
 - errno name
 - errno value in Linux, and its original value if different
 - system which originally defined it
 - release date of that system

There are a few errno names which I don't think I have the
correct original system:

  EDOTDOT, ENOMEDIUM, EMEDIUMTYPE, ECANCELED,
  ENOKEY, EKEYEXPIRED, EKEYREVOKED, EKEYREJECTED,
  EOWNERDEAD, ENOTRECOVERABLE, ERFKILL

Can anybody shed some light on these ones, that would be
great, especially if they come from SysV or Unixware.

Also, if you can spot any other mistakes, let me know!

Many thanks in advance,
	Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20110324/260be8c0/attachment.html>

[TUHS] Tracing origins of errno names/numbers

[Random832]

I spent some time tracing what version of Linux itself each one was added  
in.

Note: This doesn't necessarily show that they originated with linux (the
opposite in some cases), but it should help get a good handle on dates
(for where to look in other OSes' history). And, date/version added to
linux might itself be an interesting column to include.

V7 - this is where EFAULT changed from 106 to 14
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/errno.h
Minix 1.1
http://minnie.tuhs.org/cgi-bin/utree.pl?file=Minix1.1/usr/include/errno.h
Minix 1.5 - where 0.1 apparently took its numeric assignments from
http://minnie.tuhs.org/cgi-bin/utree.pl?file=Minix1.5/include/errno.h
0.01 - first errno.h - interesting comment.
http://lxr.linux.no/linux-old+v0.01/include/errno.h
0.95 - adds ELOOP
http://lxr.linux.no/linux-old+v0.95/include/errno.h
0.96c - last errno.h
http://lxr.linux.no/linux-old+v0.96c/include/errno.h
0.97.0 has first linux/errno.h, and a whole pile of new error numbers
http://lxr.linux.no/linux-old+v0.97.0/include/linux/errno.h
0.99.0 - EWOULDBLOCK vaue changed
http://lxr.linux.no/linux-old+v0.99.0/include/linux/errno.h
0.99.14 - adds 122 EDQUOT
http://lxr.linux.no/linux-old+v0.99.14/include/linux/errno.h
2.1.34 - adds 123 and 124
http://lxr.linux.no/linux-old+v2.1.34/include/asm-i386/errno.h
2.6.10 - 125 through 129 added
http://lxr.linux.no/linux-bk+v2.6.10/include/asm-generic/errno.h

Still haven't spent the time to find:
Where 45-47 went, 51, value change of EDEADLOCK

2005-05-01 Addition of EOWNERDEAD and ENOTRECOVERABLE:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4750e2c0c59e0c84c6c036b3d96ebd88365ae7ee
(This says it was done to support an external patch, so linux is
probably not the originating system)

2009-06-03 Addition of ERFKILL
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1f87f7d3a3b42b20f34cb03f0fd1a41c3d0e27f3

2011-03-17 EHWPOISON
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69ebb83e13e514222b0ae4f8bd813a17679ed876

EDOTDOT caught my eye for some reason - maybe because it's the only one
you attributed to linux in a long list of SVr1 ones... what were 72
through 76 in SVR1?

[TUHS] Tracing origins of errno names/numbers

[Michael Davidson]

--- On Thu, 3/31/11, Random832 <random832 at fastmail.us> wrote:

EDOTDOT caught my eye for some reason - maybe because it's the only one
you attributed to linux in a long list of SVr1 ones... what were 72
through 76 in SVR1?

As the comment indicates, EDOTDOT came from "RFS" - the almost never used "remote file system" that was (optionally, I think) part of System V Release 3.

As best I can recall, that is also where several of the other error numbers in the 72 - 79 range probably came from.

Michael Davidson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20110331/d828a845/attachment.html>

[TUHS] Tracing origins of errno names/numbers

[Nick Downing]

I also looked up EDOTDOT and found reference to RFS but not much info about
it.  Why was it not used?  Not reliable enough?  I have often thought that
the stateless, idempotent NFS protocol leaves a lot to be desired due to its
inability to implement unix semantics (as discussed in the wikipedia stub
article on RFS), has this been improved with NFS4?  Should RFS be revived
and used?  Some of its features sounded quite attractive (location
transparency, etc).  It does appear to have the ability to execute a program
remotely??  What happens with regard to PIDs, home directory etc in this
case?  Does anyone know?
cheers, Nick

On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson <
michael_davidson at pacbell.net> wrote:

> --- On *Thu, 3/31/11, Random832 <random832 at fastmail.us>* wrote:
>
>
> EDOTDOT caught my eye for some reason - maybe because it's the only one
> you attributed to linux in a long list of SVr1 ones... what were 72
> through 76 in SVR1?
>
>
> As the comment indicates, EDOTDOT came from "RFS" - the almost never used
> "remote file system" that was (optionally, I think) part of System V Release
> 3.
>
> As best I can recall, that is also where several of the other error numbers
> in the 72 - 79 range probably came from.
>
> Michael Davidson
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20110401/dcb1b911/attachment.html>

[TUHS] Tracing origins of errno names/numbers

[Larry McVoy]

If people wish to discuss RFS vs NFS, I was there are Sun when all this 
happened.

On Thu, Mar 31, 2011 at 08:26:04PM -0700, Michael Davidson wrote:
> Regardless of its technical merits (and I suspect that the implementation may have been pretty bad) RFS was doomed by AT&T's licensing policies and general ineptitude at marketing UNIX.  Similarly the widespread adoption of NFS was driven by the fact that Sun made it a de facto standard.
> 
> On Thu Mar 31st, 2011 7:51 PM PDT Nick Downing wrote:
> 
> >I also looked up EDOTDOT and found reference to RFS but not much info about
> >it.  Why was it not used?  Not reliable enough?  I have often thought that
> >the stateless, idempotent NFS protocol leaves a lot to be desired due to its
> >inability to implement unix semantics (as discussed in the wikipedia stub
> >article on RFS), has this been improved with NFS4?  Should RFS be revived
> >and used?  Some of its features sounded quite attractive (location
> >transparency, etc).  It does appear to have the ability to execute a program
> >remotely??  What happens with regard to PIDs, home directory etc in this
> >case?  Does anyone know?
> >cheers, Nick
> >
> >On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson <
> >michael_davidson at pacbell.net> wrote:
> >
> >> --- On *Thu, 3/31/11, Random832 <random832 at fastmail.us>* wrote:
> >>
> >>
> >> EDOTDOT caught my eye for some reason - maybe because it's the only one
> >> you attributed to linux in a long list of SVr1 ones... what were 72
> >> through 76 in SVR1?
> >>
> >>
> >> As the comment indicates, EDOTDOT came from "RFS" - the almost never used
> >> "remote file system" that was (optionally, I think) part of System V Release
> >> 3.
> >>
> >> As best I can recall, that is also where several of the other error numbers
> >> in the 72 - 79 range probably came from.
> >>
> >> Michael Davidson
> >>
> >> _______________________________________________
> >> TUHS mailing list
> >> TUHS at minnie.tuhs.org
> >> https://minnie.tuhs.org/mailman/listinfo/tuhs
> >>
> >>
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] Tracing origins of errno names/numbers

[John Cowan]

Michael Davidson scripsit:

> Regardless of its technical merits (and I suspect that the
> implementation may have been pretty bad) RFS was doomed by AT&T's
> licensing policies and general ineptitude at marketing UNIX.  Similarly
> the widespread adoption of NFS was driven by the fact that Sun made
> it a de facto standard.

A familiar tale: NeWS vs. X was exactly the same story, only with the players
reversed.

-- 
John Cowan  cowan at ccil.org   http://www.ccil.org/~cowan
Dievas dave dantis; Dievas duos duonos          --Lithuanian proverb
Deus dedit dentes; deus dabit panem             --Latin version thereof
Deity donated dentition;
  deity'll donate doughnuts                     --English version by Muke Tever
God gave gums; God'll give granary              --Version by Mat McVeagh

[TUHS] Tracing origins of errno names/numbers

[Michael Davidson]

Regardless of its technical merits (and I suspect that the implementation may have been pretty bad) RFS was doomed by AT&T's licensing policies and general ineptitude at marketing UNIX.  Similarly the widespread adoption of NFS was driven by the fact that Sun made it a de facto standard.

On Thu Mar 31st, 2011 7:51 PM PDT Nick Downing wrote:

>I also looked up EDOTDOT and found reference to RFS but not much info about
>it.  Why was it not used?  Not reliable enough?  I have often thought that
>the stateless, idempotent NFS protocol leaves a lot to be desired due to its
>inability to implement unix semantics (as discussed in the wikipedia stub
>article on RFS), has this been improved with NFS4?  Should RFS be revived
>and used?  Some of its features sounded quite attractive (location
>transparency, etc).  It does appear to have the ability to execute a program
>remotely??  What happens with regard to PIDs, home directory etc in this
>case?  Does anyone know?
>cheers, Nick
>
>On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson <
>michael_davidson at pacbell.net> wrote:
>
>> --- On *Thu, 3/31/11, Random832 <random832 at fastmail.us>* wrote:
>>
>>
>> EDOTDOT caught my eye for some reason - maybe because it's the only one
>> you attributed to linux in a long list of SVr1 ones... what were 72
>> through 76 in SVR1?
>>
>>
>> As the comment indicates, EDOTDOT came from "RFS" - the almost never used
>> "remote file system" that was (optionally, I think) part of System V Release
>> 3.
>>
>> As best I can recall, that is also where several of the other error numbers
>> in the 72 - 79 range probably came from.
>>
>> Michael Davidson
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>