[PATCH] linuxabi

[PATCH] linuxabi

[Andries.Brouwer]

Hi Linus,

Something we have talked about for a long time is
separating out from the kernel headers the parts
fit for inclusion in user space.

This is a very large project, and it will take a long
time, especially if we want the user space headers to
be a pleasure to look at, instead of just a cut-n-paste
copy of whatever we find in the current headers.

Some start is required, and the very first step is
making sure that you agree with the project.
Immediately following is the choice of directory names.

Below
  (i) a small textfile "linuxabi" describing the naming
(subdirectories linuxabi and linuxabi-alpha etc of include),
  (ii) the file linuxabi/mountflags.h with definitions for
MS_RDONLY and family,
  (iii) the file linux/mountflags.h that includes
linuxabi/mountflags.h and moreover defines things like
MS_RMT_MASK and IS_NOATIME(inode), and
  (iv) the patch on fs.h that removes these defines and
adds an include line.

Andries



diff -u --recursive --new-file -X /linux/dontdiff a/Documentation/linuxabi b/Documentation/linuxabi
--- a/Documentation/linuxabi	Thu Jan  1 01:00:00 1970
+++ b/Documentation/linuxabi	Wed Oct  1 00:37:45 2003
@@ -0,0 +1,18 @@
+The subdirectories  linuxabi  and  linuxabi-$ARCH 
+(linuxabi-alpha, linuxabi-arm, ...) of linux/include
+are meant for headers that are to be used both by the kernel
+and in user space. The symbolic link  linuxabi-arch
+points at  linuxabi-$ARCH  for the current architecture.
+
+Be careful not to pollute namespace.
+
+Typical material for such headers are manifest constants
+and structures used by the kernel-userspace interface.
+
+Make sure no symbolic types like dev_t, pid_t, ino_t and
+the like are used, but only explicit types like char and
+int, or even more explicit types like uint8_t and int64_t.
+
+These headers are "append-only", in the sense that Linux
+tries to keep supporting old interfaces.
+
diff -u --recursive --new-file -X /linux/dontdiff a/include/linux/fs.h b/include/linux/fs.h
--- a/include/linux/fs.h	Sun Sep 28 12:42:16 2003
+++ b/include/linux/fs.h	Wed Oct  1 01:40:04 2003
@@ -19,6 +19,7 @@
 #include <linux/cache.h>
 #include <linux/radix-tree.h>
 #include <linux/kobject.h>
+#include <linux/mountflags.h>
 #include <asm/atomic.h>
 
 struct iovec;
@@ -91,42 +92,8 @@
 #define FS_REQUIRES_DEV 1 
 #define FS_REVAL_DOT	16384	/* Check the paths ".", ".." for staleness */
 #define FS_ODD_RENAME	32768	/* Temporary stuff; will go away as soon
-				  * as nfs_rename() will be cleaned up
-				  */
-/*
- * These are the fs-independent mount-flags: up to 32 flags are supported
- */
-#define MS_RDONLY	 1	/* Mount read-only */
-#define MS_NOSUID	 2	/* Ignore suid and sgid bits */
-#define MS_NODEV	 4	/* Disallow access to device special files */
-#define MS_NOEXEC	 8	/* Disallow program execution */
-#define MS_SYNCHRONOUS	16	/* Writes are synced at once */
-#define MS_REMOUNT	32	/* Alter flags of a mounted FS */
-#define MS_MANDLOCK	64	/* Allow mandatory locks on an FS */
-#define MS_DIRSYNC	128	/* Directory modifications are synchronous */
-#define MS_NOATIME	1024	/* Do not update access times. */
-#define MS_NODIRATIME	2048	/* Do not update directory access times */
-#define MS_BIND		4096
-#define MS_MOVE		8192
-#define MS_REC		16384
-#define MS_VERBOSE	32768
-#define MS_POSIXACL	(1<<16)	/* VFS does not apply the umask */
-#define MS_ONE_SECOND	(1<<17)	/* fs has 1 sec a/m/ctime resolution */
-#define MS_ACTIVE	(1<<30)
-#define MS_NOUSER	(1<<31)
-
-/*
- * Superblock flags that can be altered by MS_REMOUNT
- */
-#define MS_RMT_MASK	(MS_RDONLY|MS_SYNCHRONOUS|MS_MANDLOCK|MS_NOATIME|\
-			 MS_NODIRATIME)
-
-/*
- * Old magic mount flag and mask
- */
-#define MS_MGC_VAL 0xC0ED0000
-#define MS_MGC_MSK 0xffff0000
-
+				 * as nfs_rename() will be cleaned up
+				 */
 /* Inode flags - they have nothing to superblock flags now */
 
 #define S_SYNC		1	/* Writes are synced at once */
@@ -138,38 +105,12 @@
 #define S_NOQUOTA	64	/* Inode is not counted to quota */
 #define S_DIRSYNC	128	/* Directory modifications are synchronous */
 
-/*
- * Note that nosuid etc flags are inode-specific: setting some file-system
- * flags just means all the inodes inherit those flags by default. It might be
- * possible to override it selectively if you really wanted to with some
- * ioctl() that is not currently implemented.
- *
- * Exception: MS_RDONLY is always applied to the entire file system.
- *
- * Unfortunately, it is possible to change a filesystems flags with it mounted
- * with files in use.  This means that all of the inodes will not have their
- * i_flags updated.  Hence, i_flags no longer inherit the superblock mount
- * flags, so these have to be checked separately. -- rmk@arm.uk.linux.org
- */
-#define __IS_FLG(inode,flg) ((inode)->i_sb->s_flags & (flg))
-
-#define IS_RDONLY(inode) ((inode)->i_sb->s_flags & MS_RDONLY)
-#define IS_SYNC(inode)		(__IS_FLG(inode, MS_SYNCHRONOUS) || \
-					((inode)->i_flags & S_SYNC))
-#define IS_DIRSYNC(inode)	(__IS_FLG(inode, MS_SYNCHRONOUS|MS_DIRSYNC) || \
-					((inode)->i_flags & (S_SYNC|S_DIRSYNC)))
-#define IS_MANDLOCK(inode)	__IS_FLG(inode, MS_MANDLOCK)
-
 #define IS_QUOTAINIT(inode)	((inode)->i_flags & S_QUOTA)
-#define IS_NOQUOTA(inode)	((inode)->i_flags & S_NOQUOTA)
 #define IS_APPEND(inode)	((inode)->i_flags & S_APPEND)
 #define IS_IMMUTABLE(inode)	((inode)->i_flags & S_IMMUTABLE)
-#define IS_NOATIME(inode)	(__IS_FLG(inode, MS_NOATIME) || ((inode)->i_flags & S_NOATIME))
-#define IS_NODIRATIME(inode)	__IS_FLG(inode, MS_NODIRATIME)
-#define IS_POSIXACL(inode)	__IS_FLG(inode, MS_POSIXACL)
-#define IS_ONE_SECOND(inode)	__IS_FLG(inode, MS_ONE_SECOND)
-
 #define IS_DEADDIR(inode)	((inode)->i_flags & S_DEAD)
+#define IS_NOQUOTA(inode)	((inode)->i_flags & S_NOQUOTA)
+
 
 /* the read-only stuff doesn't really belong here, but any other place is
    probably as bad and I don't want to create yet another include file. */
diff -u --recursive --new-file -X /linux/dontdiff a/include/linux/mountflags.h b/include/linux/mountflags.h
--- a/include/linux/mountflags.h	Thu Jan  1 01:00:00 1970
+++ b/include/linux/mountflags.h	Wed Oct  1 01:41:42 2003
@@ -0,0 +1,40 @@
+#ifndef _LINUX_MOUNTFLAGS_H
+#define _LINUX_MOUNTFLAGS_H
+
+#include <linuxabi/mountflags.h>
+
+/*
+ * Superblock flags that can be altered by MS_REMOUNT
+ */
+#define MS_RMT_MASK	(MS_RDONLY|MS_SYNCHRONOUS|MS_MANDLOCK|MS_NOATIME|\
+			 MS_NODIRATIME)
+
+/*
+ * Note that nosuid etc flags are inode-specific: setting some file-system
+ * flags just means all the inodes inherit those flags by default. It might be
+ * possible to override it selectively if you really wanted to with some
+ * ioctl() that is not currently implemented.
+ *
+ * Exception: MS_RDONLY is always applied to the entire file system.
+ *
+ * Unfortunately, it is possible to change a filesystems flags with it mounted
+ * with files in use.  This means that all of the inodes will not have their
+ * i_flags updated.  Hence, i_flags no longer inherit the superblock mount
+ * flags, so these have to be checked separately. -- rmk@arm.uk.linux.org
+ */
+#define __IS_FLG(inode,flg) ((inode)->i_sb->s_flags & (flg))
+
+#define IS_RDONLY(inode)        __IS_FLG(inode, MS_RDONLY)
+#define IS_MANDLOCK(inode)	__IS_FLG(inode, MS_MANDLOCK)
+#define IS_NODIRATIME(inode)	__IS_FLG(inode, MS_NODIRATIME)
+#define IS_POSIXACL(inode)	__IS_FLG(inode, MS_POSIXACL)
+#define IS_ONE_SECOND(inode)	__IS_FLG(inode, MS_ONE_SECOND)
+
+#define IS_SYNC(inode)	       (__IS_FLG(inode, MS_SYNCHRONOUS) || \
+				       ((inode)->i_flags & S_SYNC))
+#define IS_DIRSYNC(inode)      (__IS_FLG(inode, MS_SYNCHRONOUS|MS_DIRSYNC) || \
+				       ((inode)->i_flags & (S_SYNC|S_DIRSYNC)))
+#define IS_NOATIME(inode)      (__IS_FLG(inode, MS_NOATIME) || \
+				       ((inode)->i_flags & S_NOATIME))
+
+#endif /* _LINUX_MOUNTFLAGS_H */
diff -u --recursive --new-file -X /linux/dontdiff a/include/linuxabi/mountflags.h b/include/linuxabi/mountflags.h
--- a/include/linuxabi/mountflags.h	Thu Jan  1 01:00:00 1970
+++ b/include/linuxabi/mountflags.h	Wed Oct  1 00:40:50 2003
@@ -0,0 +1,32 @@
+#ifndef _LINUXABI_MOUNTFLAGS_H
+#define _LINUXABI_MOUNTFLAGS_H
+
+/*
+ * These are the fs-independent mount-flags: up to 32 flags are supported
+ */
+#define MS_RDONLY	 1	/* Mount read-only */
+#define MS_NOSUID	 2	/* Ignore suid and sgid bits */
+#define MS_NODEV	 4	/* Disallow access to device special files */
+#define MS_NOEXEC	 8	/* Disallow program execution */
+#define MS_SYNCHRONOUS	16	/* Writes are synced at once */
+#define MS_REMOUNT	32	/* Alter flags of a mounted FS */
+#define MS_MANDLOCK	64	/* Allow mandatory locks on an FS */
+#define MS_DIRSYNC	128	/* Directory modifications are synchronous */
+#define MS_NOATIME	1024	/* Do not update access times. */
+#define MS_NODIRATIME	2048	/* Do not update directory access times */
+#define MS_BIND		4096
+#define MS_MOVE		8192
+#define MS_REC		16384
+#define MS_VERBOSE	32768
+#define MS_POSIXACL	(1<<16)	/* VFS does not apply the umask */
+#define MS_ONE_SECOND	(1<<17)	/* fs has 1 sec a/m/ctime resolution */
+#define MS_ACTIVE	(1<<30)
+#define MS_NOUSER	(1<<31)
+
+/*
+ * Old magic mount flag and mask
+ */
+#define MS_MGC_VAL 0xC0ED0000
+#define MS_MGC_MSK 0xffff0000
+
+#endif /* _LINUXABI_MOUNTFLAGS_H */

Re: [PATCH] linuxabi

[Bernd Eckenfels]

In article <UTC200310010001.h9101NU17078.aeb@smtp.cwi.nl> you wrote:
> +These headers are "append-only", in the sense that Linux
> +tries to keep supporting old interfaces.

I dont think this is true. Neighter was is true in the past nor is it
desireable in all cases. We may define a range of releases, where the ABI
will be stable, but I am not sure we find a text everybody agrees on.

I do think it is not a bead idea to keep deprecated values at least
commented out, to avoid reuse, whenever possible.

Otherwise I love the idea. Have you checked back with the Glibc folks?

> +#define MS_NODIRATIME  2048    /* Do not update directory access times */
> +#define MS_BIND                4096
> +#define MS_POSIXACL    (1<<16) /* VFS does not apply the umask */

can we clean that up? with shifting, without shifting, with comments and without comments? I suggest to use the linuxdoc comments mandatory for the abi files.

> + * Old magic mount flag and mask

i also suggest to think twice about using the word old somewhere.
valid-since, deprecated-after may be used in conjunction with version
identifiers. And not including deprecated symbols is also a good start.

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: [PATCH] linuxabi

[viro]

On Wed, Oct 01, 2003 at 04:05:57AM +0200, Bernd Eckenfels wrote:
 
> > +#define MS_NODIRATIME  2048    /* Do not update directory access times */
> > +#define MS_BIND                4096
> > +#define MS_POSIXACL    (1<<16) /* VFS does not apply the umask */
> 
> can we clean that up? with shifting, without shifting, with comments and without comments? I suggest to use the linuxdoc comments mandatory for the abi files.


... and make it enum, while we are at it.  It's cleaner, it survives cpp
and it can be handled by gdb et.al. in sane way.

Unless we really want to support pre-v7 compilers, there is no benefit
in using #define for such constants.

Re: [PATCH] linuxabi

[H. Peter Anvin]

Followup to:  <20031001033437.GP7665@parcelfarce.linux.theplanet.co.uk>
By author:    viro@parcelfarce.linux.theplanet.co.uk
In newsgroup: linux.dev.kernel
>
> On Wed, Oct 01, 2003 at 04:05:57AM +0200, Bernd Eckenfels wrote:
>  
> > > +#define MS_NODIRATIME  2048    /* Do not update directory access times */
> > > +#define MS_BIND                4096
> > > +#define MS_POSIXACL    (1<<16) /* VFS does not apply the umask */
> > 
> > can we clean that up? with shifting, without shifting, with comments and without comments? I suggest to use the linuxdoc comments mandatory for the abi files.
> 
> 
> ... and make it enum, while we are at it.  It's cleaner, it survives cpp
> and it can be handled by gdb et.al. in sane way.
> 
> Unless we really want to support pre-v7 compilers, there is no benefit
> in using #define for such constants.

... except you can use #ifdef to test for obsolete headers.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] linuxabi

[Philippe Troin]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Followup to:  <20031001033437.GP7665@parcelfarce.linux.theplanet.co.uk>
> By author:    viro@parcelfarce.linux.theplanet.co.uk
> In newsgroup: linux.dev.kernel
> >
> > On Wed, Oct 01, 2003 at 04:05:57AM +0200, Bernd Eckenfels wrote:
> >  
> > > > +#define MS_NODIRATIME  2048    /* Do not update directory access times */
> > > > +#define MS_BIND                4096
> > > > +#define MS_POSIXACL    (1<<16) /* VFS does not apply the umask */
> > > 
> > > can we clean that up? with shifting, without shifting, with comments and without comments? I suggest to use the linuxdoc comments mandatory for the abi files.
> > 
> > 
> > ... and make it enum, while we are at it.  It's cleaner, it survives cpp
> > and it can be handled by gdb et.al. in sane way.
> > 
> > Unless we really want to support pre-v7 compilers, there is no benefit
> > in using #define for such constants.
> 
> ... except you can use #ifdef to test for obsolete headers.

A common uber-ugly trick (seen in Solaris headers) to solve this
problem is:

  enum {
  #define FOO FOO
    FOO,
  #define BAR BAR
    BAR
  } 

Phil.

Re: [PATCH] linuxabi

[Miles Bader]

Philippe Troin <phil@fifi.org> writes:
> A common uber-ugly trick (seen in Solaris headers) to solve this
> problem is:
> 
>   enum {
>   #define FOO FOO
>     FOO,

I always thought this trick was kind of cool, despite the slight
increase in ugliness for the enum definition.

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: [PATCH] linuxabi

[J.A. Magallon]

On 10.01, Andries.Brouwer@cwi.nl wrote:
> Hi Linus,
> 
> Something we have talked about for a long time is
> separating out from the kernel headers the parts
> fit for inclusion in user space.
> 
> This is a very large project, and it will take a long
> time, especially if we want the user space headers to
> be a pleasure to look at, instead of just a cut-n-paste
> copy of whatever we find in the current headers.
> 
> Some start is required, and the very first step is
> making sure that you agree with the project.
> Immediately following is the choice of directory names.
> 
> Below
>   (i) a small textfile "linuxabi" describing the naming
> (subdirectories linuxabi and linuxabi-alpha etc of include),

Why not just 'abi' ? Simpler, and allows glibc to include
just 'abi/xxxx' in other systems if they follow the same convention (BSD?) ?

Where would this live in userspace, /usr/include/abi or /usr/include/linux/abi ?
How would this relate to current /usr/include/linux 
(symlink /usr/include/linux to /usr/include/abi) ?

Just curious.

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre5-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

Re: [PATCH] linuxabi

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 04:34:37AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Oct 01, 2003 at 04:05:57AM +0200, Bernd Eckenfels wrote:
>  
> > > +#define MS_NODIRATIME  2048    /* Do not update directory access times */
> > > +#define MS_BIND                4096
> > > +#define MS_POSIXACL    (1<<16) /* VFS does not apply the umask */
> > 
> > can we clean that up? with shifting, without shifting, with comments and without comments? I suggest to use the linuxdoc comments mandatory for the abi files.
> 
> 
> ... and make it enum, while we are at it.  It's cleaner, it survives cpp
> and it can be handled by gdb et.al. in sane way.
> 
> Unless we really want to support pre-v7 compilers, there is no benefit
> in using #define for such constants.

... although with -g3 the GDB argument goes away; but I'm not arguing
about the surviving-cpp part.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] linuxabi

[Eric W. Biederman]

Andries.Brouwer@cwi.nl writes:

> Hi Linus,
> 
> Something we have talked about for a long time is
> separating out from the kernel headers the parts
> fit for inclusion in user space.
> 
> This is a very large project, and it will take a long
> time, especially if we want the user space headers to
> be a pleasure to look at, instead of just a cut-n-paste
> copy of whatever we find in the current headers.
> 
> Some start is required, and the very first step is
> making sure that you agree with the project.
> Immediately following is the choice of directory names.

This is a 2.7 project.  Doing this right requires a lot more
than what you are doing here.

One example is that we need to be very careful with is that the
glibc abi is not the same as the linux kernel abi.  Even though most
of the functions are pass through some are not.  And which are which
is a fairly arbitrary decision.  So all of the definitions exported
through linuxabi need to be in a linux centric namespace.  This is
especially true because otherwise I could not include
linuxabi/mountflags.h and sys/mount.h and not get compilation 
conflicts.

I believe linuxabi/mountflags.h should look more like:
--- a/include/linuxabi/mountflags.h	Thu Jan  1 01:00:00 1970
+++ b/include/linuxabi/mountflags.h	Wed Oct  1 00:40:50 2003
@@ -0,0 +1,32 @@
+#ifndef _LINUXABI_MOUNTFLAGS_H
+#define _LINUXABI_MOUNTFLAGS_H
+
+/*
+ * These are the fs-independent mount-flags: up to 32 flags are supported
+ */
+#define LINUX_MS_RDONLY	 1	/* Mount read-only */
+#define LINUX_MS_NOSUID	 2	/* Ignore suid and sgid bits */
+#define LINUX_MS_NODEV	 4	/* Disallow access to device special files */
+#define LINUX_MS_NOEXEC	 8	/* Disallow program execution */
+#define LINUX_MS_SYNCHRONOUS	16	/* Writes are synced at once */
+#define LINUX_MS_REMOUNT	32	/* Alter flags of a mounted FS */
+#define LINUX_MS_MANDLOCK	64	/* Allow mandatory locks on an FS */
+#define LINUX_MS_DIRSYNC	128	/* Directory modifications are synchronous */
+#define LINUX_MS_NOATIME	1024	/* Do not update access times. */
+#define LINUX_MS_NODIRATIME	2048	/* Do not update directory access times */
+#define LINUX_MS_BIND		4096
+#define LINUX_MS_MOVE		8192
+#define LINUX_MS_REC		16384
+#define LINUX_MS_VERBOSE	32768
+#define LINUX_MS_POSIXACL	(1<<16)	/* VFS does not apply the umask */
+#define LINUX_MS_ONE_SECOND	(1<<17)	/* fs has 1 sec a/m/ctime resolution */
+#define LINUX_MS_ACTIVE	(1<<30)
+#define LINUX_MS_NOUSER	(1<<31)
+
+/*
+ * Old magic mount flag and mask
+ */
+#define LINUX_MS_MGC_VAL 0xC0ED0000
+#define LINUX_MS_MGC_MSK 0xffff0000
+
+#endif /* _LINUXABI_MOUNTFLAGS_H */


Eric

Re: [PATCH] linuxabi

[Andries Brouwer]

On Thu, Oct 02, 2003 at 08:39:50AM -0600, Eric W. Biederman wrote:

> This is a 2.7 project.

I disagree. This is unrelated to kernel development, just like working
on sparse is unrelated to kernel development. 

> Doing this right requires a lot more
> than what you are doing here.

Possibly. So we need discussion.

I have registered comment #1: Al prefers the enum style.
A possibility.

Now you come with comment #2: write LINUX_MS_RDONLY instead of
MS_RDONLY. You have not convinced me.

> One example is that we need to be very careful with is that the
> glibc abi is not the same as the linux kernel abi.  Even though most
> of the functions are pass through some are not.  And which are which
> is a fairly arbitrary decision.  So all of the definitions exported
> through linuxabi need to be in a linux centric namespace.  This is
> especially true because otherwise I could not include
> linuxabi/mountflags.h and sys/mount.h and not get compilation 
> conflicts.

Today glibc tells me in sys/mount.h
 #define MS_RMT_MASK (MS_RDONLY | MS_MANDLOCK)
and in linux/fs.h
 #define MS_RMT_MASK (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_SYNCHRONOUS|MS_MANDLOCK|MS_NOATIME|MS_NODIRATIME)

It seems glibc is not even self-consistent.
Consider linuxabi/mountflags.h as part of the replacement for linux/fs.h.

Andries

Re: [PATCH] linuxabi

[Eric W. Biederman]

Andries Brouwer <aebr@win.tue.nl> writes:

> On Thu, Oct 02, 2003 at 08:39:50AM -0600, Eric W. Biederman wrote:
> 
> > This is a 2.7 project.
> 
> I disagree. This is unrelated to kernel development, just like working
> on sparse is unrelated to kernel development. 

Granted.  The major point is that it requires a development cycle
before it is ready.  Only if this is to be maintained as part of
the kernel is it needed to be 2.7 work.

> > Doing this right requires a lot more
> > than what you are doing here.
> 
> Possibly. So we need discussion.
> 
> I have registered comment #1: Al prefers the enum style.
> A possibility.
> 
> Now you come with comment #2: write LINUX_MS_RDONLY instead of
> MS_RDONLY. You have not convinced me.

My point is that we need to cleanly handle the fact that glibc
defines it's own abi that is not equivalent to the kernel abi.
A linux specific namespace does that.  After libc is done with
the definitions users will still use MS_RDONLY.

Using defines unconditionally in a private namespace is cumbersome.
A better way to go is probably:

linuxabi/features.h
....
#ifdef __USE_LINUX_NS
# define LINUX_NS(X) LINUX_##
#else
# define LINUX_NS(X) X
#endif

.....
linuxabi/mountflags.h
#include <linuxabi/features.h>
enum {
        LINUX_NS(MS_RDONLY) = 1,
	LINUX_NS(MS_NOSUID) = 2,
};

The result being that defines are placed in their own namespace
if necessary to avoid libc/kernel abi differences.

Eric

Re: [PATCH] linuxabi

[Ihar 'Philips' Filipau]

Andries Brouwer wrote:
> 
> Possibly. So we need discussion.
> 
> I have registered comment #1: Al prefers the enum style.
> A possibility.
> 
> Now you come with comment #2: write LINUX_MS_RDONLY instead of
> MS_RDONLY. You have not convinced me.
> 

   My 0.02 euro.

   LINUX_* - not right stuff. It makes a lot of sence to have the same 
name for same thing, even in different contexts. Or you are going to 
create a hell for some-one who may wish to make a documentation.

   Headers are going to be used in different context (hopefully) so 
would be no collisions (hopefully).

   Another question does GCC have something like C++'s namespace for C?
   That's would be good. Changing names - bad.

   And #define LINUX_NS(x) doesn't make sound - you will lose ability to 
grep over defines and [ce]tags will not work on this anymore. cpp is not
correct tool for namespace implementation.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: [PATCH] linuxabi

[Kai Henningsen]

aebr@win.tue.nl (Andries Brouwer)  wrote on 02.10.03 in <fa.e2g5r6g.u3igb4@ifi.uio.no>:

> Now you come with comment #2: write LINUX_MS_RDONLY instead of
> MS_RDONLY. You have not convinced me.

The argument is fairly simple.

The main idea is that we expect glibc to use these includes to talk to the  
kernel, and that we expect glibc to at least in part do that by including  
these files from the glibc includes.

So this means userspace is bound to see these declarations.

So this means namespace cleanliness issues come up.

Also, we know that glibc likes to have an ABI that's different from the  
kernel ABI.

So we can't use the POSIX names for these things, or we'd create serious  
problems for glibc actually using this stuff.

Now, what namespace to use?

I think the rules here are clear: it MUST be part of the namespace  
reserved for language implementation, which is /^_[_A-Z][a-zA-Z_0-9]*$/.  
Also, it SHOULD be something we're fairly certain nobody else will be  
using.

There's one more thing here. Sometimes things change. We should consider  
having some sort of standard way of indicating a version in the name, AND  
WE SHOULD USE IT FROM THE FIRST VERSION ON, so that there's never a need  
to change the definition of a symbol, and there's never a need to invent a  
name like new_new_new_foo.

Let me repeat and slightly rephrase that point:

Symbols in the ABI includes should *NEVER* change their definition. Use  
new symbols for new definitions. Glibc should be able to rely on knowing  
that, say, _Linux_20_stat_t will always describe the stat_t to use on  
Linux 2.0 and compatible kernels.

Remember, these things describe an ABI. To be useful, there has to be a  
1:1 correspondence between names and ABI. It's glibc above and kernel  
below who actually do compatibility conversions, it's not the job of the  
ABI descriptions. (Except in the form of comments.)

MfG Kai

Re: [PATCH] linuxabi

[Sam Ravnborg]

On Thu, Oct 02, 2003 at 08:39:50AM -0600, Eric W. Biederman wrote:
> So all of the definitions exported
> through linuxabi need to be in a linux centric namespace.

What we try to achieve is to use the same headerfiles for user,
and kernel. Previously this has been done by including selected
files direct from include/linux/*.
A few cases that I recall is DVB, scsi, and ipv6.
For all of these there were no need to create a specific linux namespace.
If there is parts of the kernel that _really_ require a separate
linux namespace then we need to find a solution for that part.
But we should not try to uglify the interface becasue a limited
part of the kernel interface have specific needs.

And since dvb, scsi and ipv6 could accept current namespace before,
they should also be able to accept it today - no?

The concept introduced by inventing abi/ is to make it visible
what part of the kernel interface is actually visible from user level.
And also a good way for us to make sure no kernel specific types sneaks in.

	Sam

Re: [PATCH] linuxabi

[Rob Landley]

On Friday 03 October 2003 02:36, Eric W. Biederman wrote:
> Andries Brouwer <aebr@win.tue.nl> writes:
> > On Thu, Oct 02, 2003 at 08:39:50AM -0600, Eric W. Biederman wrote:
> > > This is a 2.7 project.
> >
> > I disagree. This is unrelated to kernel development, just like working
> > on sparse is unrelated to kernel development.
>
> Granted.  The major point is that it requires a development cycle
> before it is ready.  Only if this is to be maintained as part of
> the kernel is it needed to be 2.7 work.

Um, what's the point of having linux abi exort header files that are NOT part 
of the kernel?

The theory here is that _some_ of the definitions in the kernel headers define 
interfaces with userspace.  Structures passed to fcntl or ioctl, constants, 
etc.  The kernel has to have copies of these definitions for its own use, 
just as much as userspace does. (It has to get the data from and put the data 
into these structures, doesn't it?  How can it do this without a defiition of 
these structures?  An interface has two sides, and the kernel side of that 
interface needs the abi definitions to provide the abi.)

The other 99% of the kernel headers should NOT get included in userspace 
programs.  This is the reason that, way back, #ifdef KERNEL was put in there 
in the first place, with the ABI stuff being anything that was outside the 
#ifdef.  This solution sucked eggs for fairly obvious reasons, but rather 
than separate out the ABI definitions into their own header files shared by 
kernel and user space, the advice from on high became "just cut and paste out 
the bits you need".  This solution sucked different eggs.  Any library that 
talks directly to the linux kernel needs to have access the kernel ABI, and 
manually extracting it from the kernel header files is a maintenance 
nightmare.  Even if you abstract this away into a library, the LIBRARY still 
needs to do it.  You've just moved the problem.

Some people here have argued variants of "tracking what the linux kernel 
exports to userspace is somebody else's problem".  I.E. the linux kernel 
can't be bothered to keep track of what it exports to userspace.  That just 
gives me a warm fuzzy feeling all over, that does...


> My point is that we need to cleanly handle the fact that glibc
> defines it's own abi that is not equivalent to the kernel abi.
> A linux specific namespace does that.  After libc is done with
> the definitions users will still use MS_RDONLY.

Does anything other than glibc have this problem?  (Does uclibc have this 
problem?  cdrecord?)

Rob

Re: [PATCH] linuxabi

[Erik Andersen]

On Fri Oct 03, 2003 at 10:37:03PM -0500, Rob Landley wrote:
> > My point is that we need to cleanly handle the fact that glibc
> > defines it's own abi that is not equivalent to the kernel abi.
> > A linux specific namespace does that.  After libc is done with
> > the definitions users will still use MS_RDONLY.
> 
> Does anything other than glibc have this problem?  (Does uclibc have this 
> problem?  cdrecord?)

glibc presents the glibc ABI to its client applications, and
uclibc presents the uclibc ABI to its clients.  If they choose to
process things a bit before communicating with their clients that
is their business.  But that is certainly not a problem for the
kernel developer's to worry about.

The means by which the various C libs present their own ABI to
their clients is also their private business.  If the kernel
developers can provide a clean ABI to user space that is not
mingled with kernel internals, you can be sure the various C lib
developers will be overjoyed to use that for kernel communication
and will gladly address any needed ABI translation.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--