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.076 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site