Messages in this thread | | | Subject | Re: [PATCH] linuxabi | From | (Eric W. Biederman) | Date | 03 Oct 2003 01:36:19 -0600 |
| |
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/
| |