lkml.org 
[lkml]   [2004]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] kbuild updates
    On Mon, 21 Jun 2004, Sam Ravnborg wrote:

    > > Many external modules, libs, etc use
    > > /lib/modules/`uname -r`/build to locate the _source_, and this will
    > > break them all.
    > Examples please. What I have seen so far is modules that was not
    > adapted to use kbuild when being build.
    > If they fail to do so they are inherently broken.
    For example our installation script expects that
    /lib/modules/`uname -r`/build behaves like a symbolic link that points to
    /usr/src/linux-`uname -r`. If /lib/modules/`uname -r`/build doesn't exist
    then /usr/src/linux-`uname -r` will be attempted instead.

    "make -C $KERNELDIR SUBDIRS=$MYDIR \
    CC=what_we_think_is_the_right_gcc_version" modules

    This approach seems to work with the "stock" kernels as well as with all
    the distribution kernels what we have tried so far (except the latest
    kernel from SuSE that used different directory scheme).

    It's relatively easy to use the dual directory scheme provided that the
    object and source directories always have the same naming. However it's
    possible that in the future there will be much more projects that need to
    compile external modules. So it would be easier in general if the
    (possible) dual directory scheme is "hidden" from the external projects.

    It should be easy difficult to patch the Makefile in
    /lib/modules/`uname -r`/build to locate the object directory without
    requiring the caller to pass it as a parameter to the "make modules"
    command.


    There is one special problem that doesn't affect users who have compiled
    their kernel themselves. Many distributions don't include gcc, make and
    related tools in the default installation so large amount of customer
    sites don't have them installed. In addition different gcc version may
    have to be used to compile the kernel than the one that is the default gcc
    command in the system. So before anything can be compiled the installation
    scripts have to check also if the required tools are installed. If they
    are not available then the customer needs to be instructed to install
    them. Because the installation procedure depents on the distribution it's
    very difficult to help the customer in any way. For this reason it would
    be better if the re is some kind of unbrella script for building the
    module. In the vanilla kernels it simply executes the right make command.
    If the distribution vendors see it necessary they can improve the script
    and add features like automatic installation of the required modules or
    whatever else.

    Does something like the following sound good?

    sh /lib/modules/`uname -r`/build/make_module $MYSUBDIR CC=$CC

    $MYSUBDIR is the absolute path to the directory where the module sources
    are located.

    $CC is optional parameter that the calling module can use if it thinks it
    knows the right gcc version. If nothing is given then plain gcc is
    assumed. If the script knows the right compiler then it overrides this
    parameter.

    In the minimalistic form the script is just

    #!/bin/sh
    make -C /lib/modules/`uname -r`/build SUBDIRS="$1" $2 modules

    Best regards,

    Hannu
    -----
    Hannu Savolainen (hannu@opensound.com)
    http://www.opensound.com (Open Sound System (OSS))
    http://www.compusonic.fi (Finnish OSS pages)
    OH2GLH QTH: Karkkila, Finland LOC: KP20CM
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.024 / U:30.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site