Keith Owens wrote:
>
> On Thu, 21 Jun 2001 22:38:20 -0600,
> "D. Stimits" <stimits@xxxxxxxxxx> wrote:
> >One snag you might be running into is that RH 7.1 makes directories
> >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies
> >of their kernel. You probably want to cd to /usr/include, and rename
> >(mv) asm, linux, and scsi, to some backup. Then also expand on their
> >symbolic links at /usr/src/.
>
> Please do not do that. Linus and other kernel maintainers fought a
> long and hard battle to stop distributions making symlinks from
> /usr/include to /usr/src/linux, or to any other active kernel.
>
> The files in /usr/include are for user space applications that need a
> stable set of includes. These must not change depending on which
> kernel you have installed this week.
Conceptually, in most practical ways, I understand this. But in the case
of device drivers or hardware that might be compiled, if it does
something like #include <linux/something.h>, and something.h has changed
in the kernel, it could cause other problems than just compile
incompatibilities. For example, modules that are compiled separately
from the kernel (because they are not patched in to the kernel or
otherwise not part of the kernel source tree, such as cvs releases of
many modules). If all of the writers of kernel-dependent code
(distributed separately from a kernel) use a #include with an absolute
path, e.g.:
#include "/usr/src/linux/include/something.h"
...then it would always work as advertised. It sounds like maybe it is a
good idea to keep the headers constant, but it also seems that it will
cause older software that is hardware dependent to break if it wasn't
written with this in mind. I have not grepped the NVidia code, but I
wonder if they have used the format:
#include <linux/something.h>
#include <asm/something.h>
In any case, I hadn't heard about this till now, so I guess it is time
to change then.
D. Stimits, stimits@xxxxxxxxxx
>
> User space code cannot assume that it has current kernel headers,
> instead they get headers that match glibc and other tools. User space
> code should not read kernel headers directly, instead the package
> should contain a copy of the required definitions. It is almost always
> a bad idea for user space applications to depend on kernel headers.
> Even code like modutils that hooks right into the kernel has its own
> copy of the required kernel headers, it is the only way to ensure that
> it ca be compiled on any kernel.
>
> Kernel based code must be compiled against kernel headers, not against
> /usr/include. The kernel makefiles try to avoid reading from anything
> outside the kernel.
|