Andreas Gruenbacher wrote:
> On Monday, 24 July 2006 00:57, Nathan Scott wrote:
>> On Sun, Jul 23, 2006 at 08:43:43PM +0200, Adrian Bunk wrote:
>>> Hi,
>>>
>>> how much of include/linux/xattr.h has to be part of the userspace kernel
>>> headers?
>> None, I think.
>
> None, indeed. The attr package comes with it own version of xattr.h that also
> includes definitions of XATTR_CREATE and XATTR_REPLACE.
>
However, it would be better if the ABI constants were exported, or at
least *exportable* (using a __KERNEL_XATTR_MACROS test macro or
something like that.)
-hpa
From: "H. Peter Anvin" <[email protected]>
Date: Mon, 26 Feb 2007 15:28:57 -0800
> Andreas Gruenbacher wrote:
> > On Monday, 24 July 2006 00:57, Nathan Scott wrote:
> >> On Sun, Jul 23, 2006 at 08:43:43PM +0200, Adrian Bunk wrote:
> >>> Hi,
> >>>
> >>> how much of include/linux/xattr.h has to be part of the userspace kernel
> >>> headers?
> >> None, I think.
> >
> > None, indeed. The attr package comes with it own version of xattr.h that also
> > includes definitions of XATTR_CREATE and XATTR_REPLACE.
> >
>
> However, it would be better if the ABI constants were exported, or at
> least *exportable* (using a __KERNEL_XATTR_MACROS test macro or
> something like that.)
This is the same situation as the socket.h issue we're trying
to figure out what to do about.
wrt. the socket.h case I think I'm going to revert the guilty
changeset for now until a better scheme is implemented
David Miller wrote:
>>>
>> However, it would be better if the ABI constants were exported, or at
>> least *exportable* (using a __KERNEL_XATTR_MACROS test macro or
>> something like that.)
>
> This is the same situation as the socket.h issue we're trying
> to figure out what to do about.
>
> wrt. the socket.h case I think I'm going to revert the guilty
> changeset for now until a better scheme is implemented
Indeed it is (as well as <linux/stat.h>).
I believe the use of feature macros is probably the way to go; that way
userspace can request subsets, which can vary from libc to libc.
There is, of course, the "ABI language" variant, but I don't see that
happening unless someone has a lot of time to spend on it.
-hpa
On Mon, Feb 26, 2007 at 03:52:42PM -0800, H. Peter Anvin wrote:
> David Miller wrote:
> >>>
> >>However, it would be better if the ABI constants were exported, or at
> >>least *exportable* (using a __KERNEL_XATTR_MACROS test macro or
> >>something like that.)
> >
> >This is the same situation as the socket.h issue we're trying
> >to figure out what to do about.
> >
> >wrt. the socket.h case I think I'm going to revert the guilty
> >changeset for now until a better scheme is implemented
>
> Indeed it is (as well as <linux/stat.h>).
>
> I believe the use of feature macros is probably the way to go; that way
> userspace can request subsets, which can vary from libc to libc.
>
> There is, of course, the "ABI language" variant, but I don't see that
> happening unless someone has a lot of time to spend on it.
What's the problem of exposing all these APIs unconditionally?
glibcs should either use all information from the linux/ headers
or nothing at all, but not depend on hiding some bits.
Christoph Hellwig wrote:
> What's the problem of exposing all these APIs unconditionally?
> glibcs should either use all information from the linux/ headers
> or nothing at all, but not depend on hiding some bits.
It's not always that simple. In particular, in some files there might
be typedefs or structure tags that step on libc's namespace (but are
useful to other libcs), but ABI constants that are universally useful.
One way to deal with the particular issue of structure tags which is
probably even more useful is:
#if defined(__KERNEL__) || defined(__KERNEL_EXPORT_STRUCTURES)
# define __kstruct_stat stat
#endif
struct __kstruct_stat {
/* ...foo... */
};
... which lets the libc export it into whatever namespace it wants by
#defining __kstruct macros accordingly.
-hpa
On Feb 26, 2007, at 19:10:16, H. Peter Anvin wrote:
> Christoph Hellwig wrote:
>> What's the problem of exposing all these APIs unconditionally?
>> glibcs should either use all information from the linux/ headers
>> or nothing at all, but not depend on hiding some bits.
>
> It's not always that simple. In particular, in some files there
> might be typedefs or structure tags that step on libc's namespace
> (but are useful to other libcs), but ABI constants that are
> universally useful.
>
> One way to deal with the particular issue of structure tags which
> is probably even more useful is:
>
> #if defined(__KERNEL__) || defined(__KERNEL_EXPORT_STRUCTURES)
> # define __kstruct_stat stat
> #endif
>
> struct __kstruct_stat {
> /* ...foo... */
> };
>
> ... which lets the libc export it into whatever namespace it wants
> by #defining __kstruct macros accordingly.
Not a bad idea, but it could use some extra error checking to make
sure that somebody remembers to "#define __kstruct_foo" before
"#include <linux/foo.h>" (perhaps indirectly through linux/bar.h).
Maybe something like this (plays nice with the very-basic unifdef
parsing too):
#ifdef __KERNEL__
# define __kstruct_stat stat
# define __kstruct_foo foo
# define __kstruct_bar bar
#endif
#ifdef __LINUX_KERNEL_EXPORT
# define __kstruct_stat stat
# define __kstruct_foo foo
# define __kstruct_bar bar
#endif
#ifndef __kstruct_stat
# error "Missing definition of __kstruct_stat, please insert:"
# error " #define __kstruct_stat <name-for-stat-struct>"
# error "into your C file before '#include <linux/foo.h>'"
#endif
struct __kstruct_stat {
}
Someone who wanted to keep the name __kstruct_stat could of course
"#define __kstruct_stat __kstruct_stat" easily.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
>
> Not a bad idea, but it could use some extra error checking to make sure
> that somebody remembers to "#define __kstruct_foo" before "#include
> <linux/foo.h>" (perhaps indirectly through linux/bar.h). Maybe
> something like this (plays nice with the very-basic unifdef parsing too):
>
> #ifdef __KERNEL__
> # define __kstruct_stat stat
> # define __kstruct_foo foo
> # define __kstruct_bar bar
> #endif
>
> #ifdef __LINUX_KERNEL_EXPORT
> # define __kstruct_stat stat
> # define __kstruct_foo foo
> # define __kstruct_bar bar
> #endif
>
> #ifndef __kstruct_stat
> # error "Missing definition of __kstruct_stat, please insert:"
> # error " #define __kstruct_stat <name-for-stat-struct>"
> # error "into your C file before '#include <linux/foo.h>'"
> #endif
> struct __kstruct_stat {
> }
>
> Someone who wanted to keep the name __kstruct_stat could of course
> "#define __kstruct_stat __kstruct_stat" easily.
>
True, but if someone makes errors on that level in your libc, don't you
think the fact that gcc will throw an error is sufficient? Writing that
kind of error generators is a lot of work, and probably for little gain.
-hpa