Martin Husemann mar...@duskware.de wrote:
In that case, I would suggest patching the kernel and let it return
ENODATA.
(...)
This has my vote as well.
Right, I will do that.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Hi
There is a choice to be made about returing ENOATTR or ENODATA when we
do not find an extended attribute.
Here are the existing behaviors:
1) return ENOATTR, while ENODATA is defined and has other usages: NetBSD
and MacOS X
2) return ENODATA, while ENOATTR is not defined: Linux
3) return
There is a choice to be made about returing ENOATTR or ENODATA [...]
In order to get the broader compatibility, I suggest patching our
errno.h to define ENOATTR as ENODATA. Opinions?
As a code author, I don't like this.
A similar situation already exists with EAGAIN and EWOULDBLOCK: some
On Mon, Apr 30, 2012 at 02:00:45PM +0200, Jean-Yves Migeon wrote:
Why not special case ENOATTR declaration, and let build environment
override it when needed?
cc -DENOATTR=ENODATA [...]
It is better to fix with a patch in pkgsrc, IMHO.
Martin
Martin Husemann mar...@duskware.de wrote:
It is better to fix with a patch in pkgsrc, IMHO.
Consider that Linux returns ENODATA, therefore most programs will check
that. The only programs we may encouter that will check for ENOATTR will
be from FreeBSD (are there any?) or MacOS X.
--
Emmanuel
On Mon, Apr 30, 2012 at 03:39:40PM +0200, Emmanuel Dreyfus wrote:
Consider that Linux returns ENODATA, therefore most programs will check
that. The only programs we may encouter that will check for ENOATTR will
be from FreeBSD (are there any?) or MacOS X.
I don't know - you could nuke ENOATTR
Martin Husemann mar...@duskware.de wrote:
I don't know - you could nuke ENOATTR from NetBSD and just make the kernel
return ENODATA.
I think this is the best way : ENOATTR does not seem to exist in any
standard. We only use it in extended attribute code, and there is no
situationa system call
On Mon, 30 Apr 2012, Emmanuel Dreyfus wrote:
Martin Husemann mar...@duskware.de wrote:
I don't know - you could nuke ENOATTR from NetBSD and just make the kernel
return ENODATA.
I think this is the best way : ENOATTR does not seem to exist in any
standard. We only use it in extended
Jean-Yves Migeon jeanyves.mig...@free.fr wrote:
What about backwards compat then? ENOATTR != ENODATA, so any code that
used ENOATTR will now break.
I remember reading that the attribute code was non-functional, and could
not be used. Are we sure that there is no other place where it could
Iain Hibbert plu...@rya-online.net wrote:
I used the ENOATTR symbol in some bluetooth related code
I did not notice it. Removing ENOATTR is therefore not possible since it
will break bluetooth userland code.
I can still turn extended attribute ENOATTR return code into ENODATA.
--
Emmanuel
Le 30/04/12 19:53, Emmanuel Dreyfus a écrit :
Jean-Yves Migeonjeanyves.mig...@free.fr wrote:
What about backwards compat then? ENOATTR != ENODATA, so any code that
used ENOATTR will now break.
I remember reading that the attribute code was non-functional, and could
not be used. Are we sure
Jean-Yves Migeon jeanyves.mig...@free.fr wrote:
What came up from the Linux vs FreeBSD extended attributes conventions?
I can't remember if a clear path was chosen, and the archives do not
point to anything obvious (at least to me)
The Linux API allows you to add arbitrary namespaces without
Le 30/04/12 21:32, Emmanuel Dreyfus a écrit :
Jean-Yves Migeonjeanyves.mig...@free.fr wrote:
What came up from the Linux vs FreeBSD extended attributes conventions?
I can't remember if a clear path was chosen, and the archives do not
point to anything obvious (at least to me)
The Linux API
13 matches
Mail list logo
