lkml.org 
[lkml]   [2000]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:0.030 / U:30.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site