This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: s390/s390-64 missing xattr exports
- From: Christoph Hellwig <hch at lst dot de>
- To: Andreas Gruenbacher <agruen at suse dot de>
- Cc: Andreas Jaeger <aj at suse dot de>, Roland McGrath <roland at frob dot com>, Ulrich Drepper <drepper at redhat dot com>, libc-alpha at sources dot redhat dot com, Nathan Scott <nathans at sgi dot com>, Tim Shimmin <tes at sgi dot com>
- Date: Mon, 19 Aug 2002 13:45:46 +0200
- Subject: Re: s390/s390-64 missing xattr exports
- References: <20020819075052.B2E8E1BA18@perdition.linnaean.org> <u87kinz2ap.fsf@gromit.moeb> <200208191116.13865.agruen@suse.de>
On Mon, Aug 19, 2002 at 11:16:13AM +0200, Andreas Gruenbacher wrote:
> > #include <errno.h>
> > #ifndef ENOATTR
> > # define ENOATTR ENODATA /* No such attribute */
> > #endif
>
> Arguably this is the wrong place; ENOATTR should be defined in <errno.h>.
Yes.
> would prefer a separate error number instead of reusing ENODATA, but several
> people have been running against walls, and we failed to get ENOATTR accepted
> in the kernel. (There was no feedback at all.)
What about just submitting a patch.. ;)
> > , it might go into <sys/xattr.h>.
> > Andreas, or what was the proper place for this one?
>
> We were so far using <attr/xattr.h>; that's also what the man pages document.
> I'm not sure if moving it to <sys/xattr.h> is a good idea:
I should certainly _not_ be <attr/xattr.h>. Rationale:
(1) <attr/xattr.h> is used by the libattr package, this is libc
(2) software using <attr/xattr.h> links against libattr, <xattr.h>
or <sys/xattr.h> using software doesn't (at least doesn't have to)
(3) having an own subdirectory under /usr/include for just one libc
header is silly, sharing that with one not-libc header (the
IRIX-compatible <attr/attributes.h> is even more silly
> (-) it's not a POSIX/etc. standard header, and not portable in any way. We
> might get name clashes later.
POSIX could aswell use the <attr/*.h> namespace - glibc has feature
macros to select standards..
> (-) it breaks existing sources. The number of utilities using it is still
> reasonably small, though.
They have to be changed to not link against libattr anyway.
> (+) if we move it, we won't run into conflicts with the attr-devel package.
> (+) the Irix EA header is <sys/attributes.h>, so it's "closer" to Irix.
IRIX API is different anyway.