errno codes intertwined

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello lists,


I am currently working on a FUSE-based filesystem much like nfs/sshfs. 
I pass the syscall on to the storage server, where it is executed, and 
get back the result, or errno code. Let's jump into the real world 
example where the storage unit is x86_64 and the mount side is 
sparc/sparc64, and the syscall is getxattr.

If a file does not have the requested attribute, the syscall will 
produce ENODATA. On x86_64, that is mapped to the value 61. Back on the 
sparc side, 61 is mapped to ECONNREFUSED, and that gives odd errors 
when ls tries to query xattrs:

18:20 sun:../ccgfs/src # ls -dl /home/profile
ls: /home/profile: Connection refused
drwx------ 13 cf users 4096 Aug 24 16:05 /home/profile

Just a grep away, this came up:

18:16 ichi:../linux-2.6.23/include > grep -r ENODATA .
./asm-alpha/errno.h:#define     ENODATA         86      /* No data available */
./asm-generic/errno.h:#define   ENODATA         61      /* No data available */
./asm-mips/errno.h:#define      ENODATA         61      /* No data available */
./asm-parisc/errno.h:#define    ENODATA         51      /* No data available */
./asm-sparc/errno.h:#define     ENODATA         111     /* No data available */
./asm-sparc/solerrno.h:#define  SOL_ENODATA        61    /* No data avail at this time       */
./asm-sparc64/errno.h:#define   ENODATA         111     /* No data available */
./asm-sparc64/solerrno.h:#define        SOL_ENODATA        61    /* No data avail at this time       */

Why do these architectures deviate from asm-generic? In fact,

./asm-alpha/errno.h:#define     ECONNREFUSED    61      /* Connection refused */
./asm-generic/errno.h:#define   ECONNREFUSED    111     /* Connection refused */
./asm-sparc/errno.h:#define     ECONNREFUSED    61      /* Connection refused */
./asm-sparc64/errno.h:#define   ECONNREFUSED    61      /* Connection refused */

the values are exactly swapped (mips is another oddball not portrayed 
here). Since these header files propagate into /usr/include, this 
affects userspace programs too.

So I'm just asking: can I rely on the same errno across Linuxes?
And should the errno values be fixed up?



	Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux