linux-2.4.0test12pre8/include/linux/module.h contains some
kernel-specific declarations that now reference struct list_head, which
which is only defined when __KERNEL__ is set. This causes sysklogd
and probably any other user level program that needs to include
<linux/module.h> to fail to compile.
The following patch brackets the (unused) offending declarations
in #ifdef __KERNEL__...#endif.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Mon, 11 Dec 2000 14:59:01 -0800,
"Adam J. Richter" <[email protected]> wrote:
> linux-2.4.0test12pre8/include/linux/module.h contains some
>kernel-specific declarations that now reference struct list_head, which
>which is only defined when __KERNEL__ is set. This causes sysklogd
>and probably any other user level program that needs to include
><linux/module.h> to fail to compile.
>
> The following patch brackets the (unused) offending declarations
>in #ifdef __KERNEL__...#endif.
Linus, please do not apply.
User space applications _must_ not include kernel headers. Even
modutils does not include linux/module.h, it has its own portable
(kernels 2.0 - 2.4) version.
I have strongly recommended to the sysklogd maintainers that they strip
all the symbol handling from klogd. The oops decoding in klogd is
hopelessly out of date and broken.
Wasn't there discussion that user space apps shouldn't include kernel
headers?
"Adam J. Richter" wrote:
>
> linux-2.4.0test12pre8/include/linux/module.h contains some
> kernel-specific declarations that now reference struct list_head, which
> which is only defined when __KERNEL__ is set. This causes sysklogd
> and probably any other user level program that needs to include
> <linux/module.h> to fail to compile.
>
> The following patch brackets the (unused) offending declarations
> in #ifdef __KERNEL__...#endif.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
} User space applications _must_ not include kernel headers. Even
} modutils does not include linux/module.h, it has its own portable
} (kernels 2.0 - 2.4) version.
There are cases where a user-program _must_ include kernel headers. Some
glibc versions have incorrect values for MCL_* and asm/mman.h has correct
versions. If you want your mlock call to do anything, you need the kernel
header.
[Mohammad A. Haque]
> Wasn't there discussion that user space apps shouldn't include kernel
> headers?
Oh, it's been discussed, many times. Here is my executive summary of
why nobody needs to use kernel headers in userspace programs, *EVER*:
Q: I want to #include <linux/foo.h> but I get compile errors, please
apply this patch to foo.h.
A: Make a copy of foo.h, fix it up to compile properly in your
application and ship it in your tarball.
Q: What if foo.h changes? My copy will be out of date and my app will
not work properly on new kernels.
A: This is exactly the same problem as userspace ABI drift. And it has
exactly the same solution: make sure userspace interfaces to kernel
functionality are as stable as possible. We really *do* try not to
gratuitously break binaries ... except certain system utilities
which are low-level enough to justify telling the user to upgrade
(and that's a short list -- see Documentation/Changes.)
Q: What about new features? What if foo.h gets some new ioctl
definitions? My copy won't have these and my app won't be able to
use them.
A: So resync with the kernel copy, when the need arises. Obviously
your app won't magically be able to just use the new functionality
without other changes on your part -- resyncing foo.h is just a
small part of the changes you are already making anyway.
Q: I maintain a subsystem with tightly-coupled userspace and kernel
components.
A: So maintain *your* header files however you wish, but just ship
separate copies in your kernel patches and userspace tarballs.
Peter
On Mon, Dec 11, 2000 at 07:53:05PM -0600, Peter Samuelson wrote:
>
> [Mohammad A. Haque]
> > Wasn't there discussion that user space apps shouldn't include kernel
> > headers?
>
> Oh, it's been discussed, many times. Here is my executive summary of
> why nobody needs to use kernel headers in userspace programs, *EVER*:
Oh, sounds reasonable. But:
Do the maintainers of strace, lm_sensors, the wacom input device in XFree
know this? (just to name a few)
The unanswered question remains:
$ cat `find linux/include/{linux,asm}/. -type f` |grep '^#ifdef __KERNEL__'|wc
246 514 4537
why is this?
Either: strip it or maintain it.
--
Frank