On Thu, 27 Apr 2000, Paul Barton-Davis wrote:
> I find this approach pretty worrying. Its *often* necessary to include
> such files in user-space programs that use ioctl to control various
> hardware resourcs (e.g. linux/rtc.h).
Sigh... What part of mount.h do you need in userland? It defines a data
structure that _never_ exists outside of kernel space and two functions
operating on it.
> I really hope that we don't have the attitude that these programs
> CANNOT be C++. All it takes to ensure header-file compatibility is
> avoidance of a few extra C++ keywords (such as "new"). I don't think
> anyone is asking for anything else.
<shrug> basically, I couldn't care less for C++ - it has no business
seeing the internal kernel stuff and that's what __KERNEL__ is for.
There is a tiny part of the kernel headers that is shared with userland,
everything else is a private kernel namespace and no userland program,
whether it is in C, C++ or BLISS-32 has a right to see it.
> If the suggestion is that *no* true kernel header should ever be
> included, but that glibc should come with its own versions of them all:
> how can this cover h/w-specific resource like the RTC etc. ?
Talk to glibc folks. Everything under #ifdef __KERNEL__ is off-limits
and the whole mount.h belongs there. Beyond that... Not a kernel business.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST