[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28616.1190217203@turing-police.cc.vt.edu>
Date: Wed, 19 Sep 2007 11:53:23 -0400
From: Valdis.Kletnieks@...edu
To: Sam Ravnborg <sam@...nborg.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc6-mm1 - Mostly working, with a kbuild oddity
On Wed, 19 Sep 2007 09:34:02 +0200, Sam Ravnborg said:
> > I had a few issues with some other modules, but they're evil binaries so
> > I'm taking those up directly with the companies involved.. ;)
>
> How annoying is this - and is this the CFLAGS thing again?
The other issues were VMWare and the removal of EXPORT_SYMBOL(set_dumpable),
and NVidia graphics driver not playing nice with x86_64-mm-cpa-clflush.patch
(these actually broke back around -rc[34]-mm1, so it's not a new issue). I
just had to spend 5 minutes re-checking that my workarounds did/didn't need
refreshing. Like I said, their problems (and mine), not lkml's.
> We could introduce some workaraound so we continue to respect
> the CFLAGS settings in a Makefile for a while.
> But at the end of the day we should convince the external module people
> to follow the Kbuild docs. So it will then be temporary.
I already sent the author a patch for the broken Makefile. I don't think an
in-tree workaround is the right thing here. I've vote for an entry in the
"What's new in 2.6.2X" document when the kbuild changes go mainline, since
fixing it to use EXTRA_CFLAGS worked perfectly. External module maintainers
have (presumably) already read stable-API-nonsense, and should be used to
fixing code for new releases, so a 1 or 2 line Makefile tweak shouldn't be a
hardship.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists