xfs
[Top] [All Lists]

Re: xfs kernel src

To: stimits@xxxxxxxxxx
Subject: Re: xfs kernel src
From: Keith Owens <kaos@xxxxxxxxxx>
Date: Fri, 22 Jun 2001 14:53:41 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Your message of "Thu, 21 Jun 2001 22:38:20 CST." <3B32CBBC.D07E7D40@idcomm.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
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.

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.


<Prev in Thread] Current Thread [Next in Thread>