include/linux/xattr.h: how much userpace visible?

include/linux/xattr.h: how much userpace visible?

[Adrian Bunk]

Hi,

how much of include/linux/xattr.h has to be part of the userspace kernel 
headers?

The function prototypes should no longer be visible in userspace.
But how much of the rest of this file is usable for userspace?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: include/linux/xattr.h: how much userpace visible?

[Alexey Dobriyan]

On Sun, Jul 23, 2006 at 08:43:43PM +0200, Adrian Bunk wrote:
> how much of include/linux/xattr.h has to be part of the userspace kernel
> headers?
>
> The function prototypes should no longer be visible in userspace.
> But how much of the rest of this file is usable for userspace?

XATTR_CREATE, XATTR_REPLACE are passed to sys_setxattr syscall.
struct xattr_handler is ours (it uses struct inode *). Prototypes are
ours.

Re: include/linux/xattr.h: how much userpace visible?

[Nathan Scott]

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.

> The function prototypes should no longer be visible in userspace.
> But how much of the rest of this file is usable for userspace?

The attr package has its own distinct copy of this file, which has
no kernel pieces - I'm not sure whether libc ended up copying this
or doing its own thing though.

cheers.

-- 
Nathan

Re: include/linux/xattr.h: how much userpace visible?

[Andreas Gruenbacher]

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.

Andreas

Re: include/linux/xattr.h: how much userpace visible?

[Sam Ravnborg]

On Mon, Jul 24, 2006 at 08:31:11PM +0200, 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.
The userspace headers are supposed to hold the part of the kernel
definitions that glibc (and mayby the attr package) uses. If they happen
to have their own copy now should not impct the decision what is part of
the userspace interface for the kernel. So actual usage does not decide
what is part of the userspace kernel headers but what definitionas are
definitions the userspace <-> kernel interface.

	Sam

Re: include/linux/xattr.h: how much userpace visible?

[Andreas Gruenbacher]

On Monday, 24 July 2006 20:45, Sam Ravnborg wrote:
> The userspace headers are supposed to hold the part of the kernel
> definitions that glibc (and mayby the attr package) uses. If they happen
> to have their own copy now should not impct the decision what is part of
> the userspace interface for the kernel. So actual usage does not decide
> what is part of the userspace kernel headers but what definitionas are
> definitions the userspace <-> kernel interface.

Sure, fine by me.

Andreas

Re: include/linux/xattr.h: how much userpace visible?

[H. Peter Anvin]

Sam Ravnborg wrote:
> The userspace headers are supposed to hold the part of the kernel
> definitions that glibc (and mayby the attr package) uses. If they happen
> to have their own copy now should not impct the decision what is part of
> the userspace interface for the kernel. So actual usage does not decide
> what is part of the userspace kernel headers but what definitionas are
> definitions the userspace <-> kernel interface.

glibc, or another libc.

Basically, the kernel should be able to export the things that userspace 
needs to be able to correctly speak the ABI.

	-hpa

Re: include/linux/xattr.h: how much userpace visible?

[H. Peter Anvin]

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

Re: include/linux/xattr.h: how much userpace visible?

[David Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
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

Re: include/linux/xattr.h: how much userpace visible?

[H. Peter Anvin]

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

Re: include/linux/xattr.h: how much userpace visible?

[Christoph Hellwig]

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.

Re: include/linux/xattr.h: how much userpace visible?

[H. Peter Anvin]

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

Re: include/linux/xattr.h: how much userpace visible?

[Kyle Moffett]

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

Re: include/linux/xattr.h: how much userpace visible?

[H. Peter Anvin]

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