Messages in this thread | | | Date | Tue, 10 Feb 2004 09:18:51 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH] warning: `__attribute_used__' redefined |
| |
On Tue, 10 Feb 2004, Daniel Jacobowitz wrote: > > This is what Debian has been using. I believe the other folks with a > glibc-kernel-headers package based on 2.6 do something similar. I > don't know how you'll feel about adding this sort of crap to the > kernel, though. Someone else needs to find time to start linuxabi > moving again...
I don't mind adding a few __KERNEL__ checks, but no I don't want code like this:
> +#if !defined(__KERNEL__) > +/* Debian: Most of these are inappropriate for userspace. */ > +/* We don't define likely, unlikely, or barrier; they're namespace-intrusive > + and should not be needed outside of __KERNEL__. For __attribute_pure__ > + and __attribute_used__ we use glibc's definitions. */ > +# include <sys/cdefs.h> > +# define __deprecated > +#else
that is completely glibc-dependent and has no meaning in a kernel header file.
In general, anything that uses most of the kernel special magic defines (__deprecated, __inline__, etc) probably should be inside #ifdef __KERNEL__ anyway, so the kernel <linux/compiler.h> file should not need to define them.
There are a few cases that look special, just because they touch data structures that are actually visible to user space. That would be things like "__packed__" and "__user" etc, which are used to tell something about the data structure.
So right now I just added a "#ifdef __KERNEL__" around the special parts, and did _not_ do the part about. We can add a few more #ifdef's around something else that breaks, but in general I feel that this is up to whoever merges the headers into user space.
Linus - 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/
| |