lkml.org 
[lkml]   [2003]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] linuxabi
From
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.069 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site