lkml.org 
[lkml]   [2004]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] kbuild updates
    On Sun, Jun 20, 2004 at 11:26:54PM +0100, Alistair John Strachan wrote:
    > [snipped a few CC addresses]
    >
    > On Sunday 20 June 2004 23:16, Martin Schlemmer wrote:
    > > On Mon, 2004-06-21 at 00:03, Sam Ravnborg wrote:
    > > > On Sun, Jun 20, 2004 at 11:30:34PM +0200, Martin Schlemmer wrote:
    > > > > I know Sam's mta blocks my mail at least (lame isp), but for the rest,
    > > > > please reconsider using this.
    > > >
    > > > Hmm, got your mail.
    > > >
    > > > > 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.
    > >
    > > Well, glibc use it for instance as an fall-through if you do not specify
    > > it via ./configure arguments, or environment (yes, glibc should not use
    > > it, etc, etc, no flames please =). So as well does alsa-driver,
    > > nvidia's drivers (gah, puke, yes, its got some binary-only stuff in
    > > there ;), ati's drivers and a lot of other stuff (if you really need
    > > them all I can try to find time to look for more).
    > >
    > > I am not sure about ati's drivers and alsa, but nvidia uses kbuild.
    > >
    > >
    > > Thanks,
    >
    > Sam's point is that unless you ask KBUILD to put the kernel build in a
    > separate directory to its sources (this is not the default
    > behaviour), /lib/modules/`uname -r`/build will still point to the mixture of
    > source and build data, therefore no breakage will occur.

    Correct!

    > I understand Sam's reasoning and I believe it is sensible to have the source
    > and build output in separate directories within /lib/modules/`uname -r`. The
    > drivers in question can easily be updated to support the exceptional case
    > whereby users build kernels in a different directory to the source.
    >
    > Sam, maybe if there was a way to easily detect whether a kernel had been build
    > with or without a different output directory, it would be easier to have
    > vendors take this change on board. For example, I imagine in the typical case
    > whereby no change in build directory is made, you will have something like
    > this:
    >
    > /lib/modules/2.6.7/build -> /home/alistair/linux-2.6
    > /lib/modules/2.6.7/source -> /home/alistair/linux-2.6
    >
    > Whereas when O is given, it will instead be like this:
    >
    > /lib/modules/2.6.7/build -> /home/alistair/my-dir
    > /lib/modules/2.6.7/source -> /home/alistair/linux-2.6
    >
    > I presume that checking for the existence of /lib/modules/`uname -r`/source
    > will be enough.
    >
    > #
    > # where's the kernel source?
    > #
    >
    > if [ -d /lib/modules/`uname -r`/source ]; then
    > # 2.6.8 and newer
    > KERNDIR="/lib/modules/`uname -r`/source"
    > else
    > # pre 2.6.8 kernels
    > KERNDIR="/lib/modules/`uname -r`/build"
    > fi

    Look ok.

    Sam
    -
    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:04    [W:0.025 / U:119.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site