Re: [PATCH] linuxabi

Eric W. Biederman
2003-10-03T07:37:14Z

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