On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >It was at that
> >point, the externally compiled module "barfed", because like many modules,
> >it expected, like many externally compiled modules, that it could simply
> >access all of it's needed files through /usr/include/linux which it gets
> >by putting /usr/include in it's path. I've seen commercial modules like
> >vmware's kernel modules use a similar system where they expect
> >/usr/include/linux to contain or point to headers for the currently running
> >kernel.
>
> vmware asks you nicely
>
> where are the running kernels include files [/usr/src/linux/include" >
>
> And then compiles the modules with -I/path/to/include/files
>
> In fact, the 2.2.18 kernel already puts a 'build' symlink in
> /lib/modules/`uname -r` that points to the kernel source,
> which should be sufficient to solve this problem.. almost.
>
> It doesn't tell you the specific flags used to compile the kernel,
> such as -m486 -DCPU=686
>
> > So at that point it becomes what we should name it under
> >/usr/include/linux. Should it be:
> >1) "/usr/include/linux/sys" (my preference)
>
> /usr should be static. It could be a read-only NFS mount.
> Putting system dependant configuration info here (which a
> /usr/include/linux/sys symlink *is*) is wrong.
>
> I think /lib/modules/`uname -r`/ should contain a script that
> reproduces the CFLAGS used to compile the kernel. That way,
> you not only get the correct -I/path/to/kernel/include but
> the other compile-time flags (like -m486 etc) as well.
[snip script]
However it happens, the necessary information THAT I KNOW OF is:
0) The kernel headers under linux/include
1) The state information generated by running make configure ; make dep ;
make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
configure which does the same thing but adds packaging-specific metadata.
A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
will not always work, because:
0) The destination may not even exist (if the kernel has been installed
onto another machine)
1) The destination has no metadata or has the WRONG metadata (if I've just
compiled and installed 2.4.0-test11 on my i386, then am now building same
for my sun4c)
I have been recently told that a full copy of kernel headers and metadata
in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
who informed me of this hasn't yet shown why.
Debian's kernel package system allows for the creation of a kernel-headers
package which I THINK contains the correct metadata, but I've not
verified. This is placed into /usr/src/kernel-headers-`uname -r`/. This is
distro-specific but still A technically sound solution AFAIK. And not much
different than mentioned in the directly preceding paragraph.
Who else can offer an alternative solution, to the specific problem of
making configured KERNEL headers available for building third-party
modules?
--Ferret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
