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
--
On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote:
...
> 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:
I'd think that passing the raw error code is a bad idea, and that you
probably want to have your own set of codes that you use in the trasport and
map value to/from the host's errno values.
> 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.
Yep, and it kind of sucks.
> So I'm just asking: can I rely on the same errno across Linuxes?
I wouldn't - Linux on different different architectures seems to have
different errno codes.
> And should the errno values be fixed up?
It would break userspace :-/
Josef 'Jeff' Sipek.
--
*NOTE: This message is ROT-13 encrypted twice for extra protection*
Jan Engelhardt <[email protected]> writes:
>
> So I'm just asking: can I rely on the same errno across Linuxes?
No. The errnos were originally designed to be compatible
with the "native" Unix on that platform to make running
their binaries easier. On Sparc that would
be SunOS/Solaris.
-Andi
From: Jan Engelhardt <[email protected]>
Date: Fri, 24 Aug 2007 18:24:48 +0200 (CEST)
> So I'm just asking: can I rely on the same errno across Linuxes?
> And should the errno values be fixed up?
You cannot rely on error numbers being the same, every
architecture has something to a few to many differences
in this area.
On Friday 24 August 2007, Jan Engelhardt wrote:
> So I'm just asking: can I rely on the same errno across Linuxes?
nope
> And should the errno values be fixed up?
i guess that depends on whether you think it's even broken :)
no spec requires any errno symbol have an exact numeric value ... i'm guessing
your FUSE is only cross-Linux and you're not planning on dipping into any
other OS ?
-mike
On Aug 26 2007 13:45, Mike Frysinger wrote:
>> can I rely on the same errno across Linuxes?
>
>nope
>
>> And should the errno values be fixed up?
>
>i guess that depends on whether you think it's even broken :)
>
>no spec requires any errno symbol have an exact numeric value ... i'm guessing
>your FUSE is only cross-Linux and you're not planning on dipping into any
>other OS ?
If the errnos are not the same in the Linux world, it's not even
cross-Linux ;-) - but it's always translated to fixed numbers now anyway.
I have not really thought about putting it in use on other systems yet. I
don't have macosx to test, and Windows generally lacks some fuses. :^)
You are free to spin it if you like, http://freshmeat.net/p/ccgfs/
Jan
--