Re: [PATCH 0/2] kbuild updates

[Martin Schlemmer <azarah@nosferatu.za.org>]

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

On Mon, 2004-06-21 at 00:26, 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.
> 
> 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
> 
> Yeah?

Yes, as said before, I can understand the name change.  The point is
more that the 'build' symlink will change in behavior in certain
circumstances, and because many projects already support 2.6, and
make use of the 'build' symlink, they will break.

If it was however done in 2.7, things will get supported well before
2.8 is out, or in general use ...

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]