kernel 2.6.x driver compiler options

kernel 2.6.x driver compiler options

[KC]

Hi,

Instead of using Linux kconfig build system, can someone tell me
what's the compiler options used to build a device driver (.ko file) ?

Or, how can I integrate kconfig with GNU tool chain (automake, autoconf ...)

Thanks
KC
kccheng@LinuxDAQ-Labs.org

Re: kernel 2.6.x driver compiler options

[Erik Mouw]

On Tue, May 10, 2005 at 04:08:30PM +0800, KC wrote:
> Instead of using Linux kconfig build system, can someone tell me
> what's the compiler options used to build a device driver (.ko file) ?

That depends on the architecture (i386, x86_64, arm, ppc, etc.),
compiler version (gcc 3.3, 3.4, 4.0, etc.), and kernel configuration
(single CPU, SMP, preempt, regparms, etc.). Kbuild knows about all
those things.

> Or, how can I integrate kconfig with GNU tool chain (automake, autoconf ...)

Create a file Makefile.kbuild with the usual stuff kbuild needs (see
http://lwn.net/Articles/21823/ ). Then make an automake Makefile.am
file like this:

all:
	$(MAKE) -f ${srcdir}/Makefile.kbuild -C ${KERNEL_DIR} \
		M=${srcdir} O=${builddir} modules

Have configure.in AC_SUBST(KERNEL_DIR), and you should be set.
I haven't tested this, but I think it should work.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: kernel 2.6.x driver compiler options

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Tue, 10 May 2005 16:08:30 +0800, KC said:

> Instead of using Linux kconfig build system, can someone tell me
> what's the compiler options used to build a device driver (.ko file) ?

There's plenty of documentation on how to use 'make' to build an
out-of-tree .ko.

> Or, how can I integrate kconfig with GNU tool chain (automake, autoconf ...)

First, describe the semantics.  How the <bleep> is that ever "supposed to work"?
automangle and friends are designed so you can configure userspace programs to
run no matter what oddities the underlying system has.  Kconfig is for actually
describing the underlying system.

At *best*, all you could do is use the .config variables to answer some of
the "is XYZ present?" tests done in ./configure - but even *that* is Pigheaded
And Wrong, because it will get it wrong if you're pulling hints from a kernel
tree that doesn't match the running kernel, or if it's a new-ish feature that
requires userspace library support that isn't installed on the system...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]