"H. Peter Anvin" wrote:
> Followup to: <11472.995579612@redhat.com>
> By author: David Woodhouse <dwmw2@infradead.org>
> In newsgroup: linux.dev.kernel
> >
> > It has been stated many times that kernel headers should not be used in
> > apps. Renaming or moving them should not be necessary - and people would
> > probably only start to use them again anyway. We'd see autoconf checks to
> > find whether it's linux/private.h or xunil/private.h :)
> >
> > In the absence of any expectation that userspace developers will ever obey
> > the simple and oft-repeated rule that you don't use kernel headers from
> > userspace, the #ifdef __KERNEL__ approach would seem to be the best on
> > offer.
> Note that the rule is at least in part theoretical; even glibc include
> kernel headers or -derivatives.
Derivatives are fine and IMHO irrelevant to the issue of __KERNEL__:
you can always do something like gcc's fixincludes.
uClibc and dietlibc do not include any kernel headers at all. And at
least one glibc developer spoke up in a previous thread and agreed that
it is not necessary to include kernel headers in glibc.
As important as glibc is, it's breaking a rule, which is a bug, that can
be fixed.
> I think the idea with <asm/bitops.h> is that they are protected by
> #ifdef __KERNEL__ if they are kernel-only; however, if they work in
> user space then there is no #ifdef and autoconf can detect their
> presence.
Any amount of sharing between userspace and kernel -adds- constraints to
kernel code, and leads to namespace pollution on both ends by careless
(or busy!) developers.
Let's remove restrictions and constraints from kernel code, not add to
them...
-- Jeff Garzik | "I wouldn't be so judgemental Building 1024 | if you weren't such a sick freak." MandrakeSoft | -- goats.com - 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/
This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 21:00:14 EST