From: miquels@traveler.cistron-office.nl (Miquel van Smoorenburg)
To: linux-kernel@vger.kernel.org
Subject: Re: Linus's include file strategy redux
Date: 15 Dec 2000 21:02:16 GMT [thread overview]
Message-ID: <91e0so$9bn$1@enterprise.cistron.net> (raw)
In-Reply-To: <20001215152137.K599@almesberger.net> <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>
In article <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>,
LA Walsh <law@sgi.com> 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.
# sh /lib/modules/`uname -r`/kconfig --cflags
-D__KERNEL__ -I/usr/src/linux-2.2.18pre24/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686
Standard module Makefile that will _always_ work:
#! /usr/bin/make -f
CC = $(shell /lib/modules/`uname -r`/kconfig --cc)
CFLAGS = $(shell /lib/modules/`uname -r`/kconfig --cflags)
module.o:
$(CC) $(CFLAGS) -c module.c
Flags could be:
--check Consistency check - are the header files there and
does include/linux/version.h match
--cc Outputs the CC variable used to compile the kernel
(important now that we have gcc, kgcc, gcc272)
--arch Outputs the ARCH variable
--cflags Outputs the CFLAGS
--include-path Outputs just the path to the include files
Generating and installing this 'kconfig' script as part of
"make modules_install" is trivial, and would solve all problems.
Well as far as I can see, ofcourse, I might have missed something..
Mike.
--
RAND USR 16514
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-15 21:33 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <91gr99$bs81o$1@fido.engr.sgi.com>
2000-12-14 23:55 ` Linus's include file strategy redux LA Walsh
2000-12-15 0:14 ` Miquel van Smoorenburg
2000-12-15 0:17 ` Alexander Viro
2000-12-15 0:39 ` Miquel van Smoorenburg
2000-12-15 0:33 ` Alan Cox
2000-12-15 0:48 ` Alexander Viro
2000-12-15 0:56 ` David Riley
2000-12-15 1:05 ` Alexander Viro
2000-12-15 4:24 ` ferret
2000-12-16 11:30 ` Marcus Sundberg
2000-12-15 14:57 ` Kurt Roeckx
2000-12-15 15:23 ` Dana Lacoste
2000-12-15 22:28 ` Alex Buell
2000-12-16 22:41 ` Peter Samuelson
2000-12-18 15:51 ` Dana Lacoste
2000-12-18 17:08 ` Peter Samuelson
2000-12-18 19:32 ` David Schleef
2000-12-18 17:04 ` richard offer
2000-12-19 5:16 ` Peter Samuelson
2000-12-15 0:15 ` Alexander Viro
2000-12-15 7:21 ` LA Walsh
2000-12-15 11:05 ` Chmouel Boudjnah
2000-12-15 14:21 ` Werner Almesberger
2000-12-15 17:15 ` ferret
2000-12-15 17:46 ` Werner Almesberger
2000-12-15 20:29 ` Joe deBlaquiere
2000-12-15 21:27 ` Werner Almesberger
2000-12-15 22:58 ` Joe deBlaquiere
2000-12-15 23:56 ` Werner Almesberger
2000-12-16 22:50 ` Peter Samuelson
2000-12-17 0:04 ` Joe deBlaquiere
2000-12-17 2:05 ` Peter Samuelson
2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg [this message]
2000-12-16 4:04 ` ferret
2000-12-16 11:09 ` Miquel van Smoorenburg
2000-12-16 17:20 ` ferret
2000-12-17 0:21 ` J . A . Magallon
2000-12-16 23:10 ` Peter Samuelson
2000-12-17 1:15 ` Miquel van Smoorenburg
2000-12-17 2:18 ` Peter Samuelson
2000-12-15 21:21 ` Werner Almesberger
2000-12-15 21:36 ` LA Walsh
2000-12-15 22:48 ` J . A . Magallon
2000-12-15 23:47 ` Werner Almesberger
2000-12-16 4:11 ` ferret
2000-12-16 2:50 ` richard offer
2000-12-16 4:22 ` What about 'kernel package'? was: " ferret
2000-12-15 19:35 ` Matt D. Robinson
2000-12-15 21:36 ` Werner Almesberger
2000-12-18 17:48 Petr Vandrovec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='91e0so$9bn$1@enterprise.cistron.net' \
--to=miquels@traveler.cistron-office.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox