Every time I (or someone else) gets a patch included
removing explicit includes of linux/config.h, another few creep
into the tree a day or so later.
Lets kill them all for good.
master.kernel.org:/pub/scm/linux/kernel/git/davej/configh.git
is a git tree killing off all the current users in tree,
and adds a #warn to include/linux/config.h that it's going away.
(This should still leave as-yet-unmerged trees compiling,
and hopefully get them fixed before they get merged)
We can then remove the file for real just before 2.6.19
Dave
--
http://www.codemonkey.org.uk
On Wed, Oct 04, 2006 at 03:44:34AM -0400, Dave Jones wrote:
> Every time I (or someone else) gets a patch included
> removing explicit includes of linux/config.h, another few creep
> into the tree a day or so later.
>
> Lets kill them all for good.
>
> master.kernel.org:/pub/scm/linux/kernel/git/davej/configh.git
>
> is a git tree killing off all the current users in tree,
> and adds a #warn to include/linux/config.h that it's going away.
> (This should still leave as-yet-unmerged trees compiling,
> and hopefully get them fixed before they get merged)
> We can then remove the file for real just before 2.6.19
Removing it for real will be a pain for external modules.
They could of course detect that it is missing and then
drop it.
I would suggest to keep the #warning in 2.6.19 and only
remove it for real for 2.6.20.
Sam
On Wed, 2006-10-04 at 13:24 +0200, Sam Ravnborg wrote:
> On Wed, Oct 04, 2006 at 03:44:34AM -0400, Dave Jones wrote:
> > Every time I (or someone else) gets a patch included
> > removing explicit includes of linux/config.h, another few creep
> > into the tree a day or so later.
> >
> > Lets kill them all for good.
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/davej/configh.git
> >
> > is a git tree killing off all the current users in tree,
> > and adds a #warn to include/linux/config.h that it's going away.
> > (This should still leave as-yet-unmerged trees compiling,
> > and hopefully get them fixed before they get merged)
> > We can then remove the file for real just before 2.6.19
>
> Removing it for real will be a pain for external modules.
> They could of course detect that it is missing and then
> drop it.
> I would suggest to keep the #warning in 2.6.19 and only
> remove it for real for 2.6.20.
they'll have to change anyway; delaying it one release doesn't actually
change that. And you can bet on most modules ignoring the warning anyway
and wait until the thing really is gone... making the value that this
extra delay has basically zero. While the cost is that more false users
will sneak into the kernel ;(
Maybe Fedora can ship with an #error here early on; an #error at least
can provide a helpful message on how to fix it.
On Wed, Oct 04, 2006 at 01:45:32PM +0200, Arjan van de Ven wrote:
> > Removing it for real will be a pain for external modules.
> > They could of course detect that it is missing and then
> > drop it.
> > I would suggest to keep the #warning in 2.6.19 and only
> > remove it for real for 2.6.20.
>
> they'll have to change anyway; delaying it one release doesn't actually
> change that. And you can bet on most modules ignoring the warning anyway
> and wait until the thing really is gone... making the value that this
> extra delay has basically zero. While the cost is that more false users
> will sneak into the kernel ;(
My thoughts exactly. Since when did we give a damn about keeping
external modules compiling anyway?
> Maybe Fedora can ship with an #error here early on; an #error at least
> can provide a helpful message on how to fix it.
The #warn has been there for a few weeks in the fc6pre kernels, but it's
easily changed.
Dave
--
http://www.codemonkey.org.uk
On Wed, Oct 04, 2006 at 02:01:22PM -0400, Dave Jones wrote:
> On Wed, Oct 04, 2006 at 01:45:32PM +0200, Arjan van de Ven wrote:
>
> > > Removing it for real will be a pain for external modules.
> > > They could of course detect that it is missing and then
> > > drop it.
> > > I would suggest to keep the #warning in 2.6.19 and only
> > > remove it for real for 2.6.20.
> >
> > they'll have to change anyway; delaying it one release doesn't actually
> > change that. And you can bet on most modules ignoring the warning anyway
> > and wait until the thing really is gone... making the value that this
> > extra delay has basically zero. While the cost is that more false users
> > will sneak into the kernel ;(
>
> My thoughts exactly. Since when did we give a damn about keeping
> external modules compiling anyway?
In kbuild quite a lot of effort has been done to make life easier
for those dealing with external modules. There are several
reasons to deal with external modules:
- Alpha stage module that is not yet ready for kernel inclusion
- Special stuff that does not belong in the kernel for som reason
- Experimental stuff of any kind
This covers maybe one fifth of all external modules but that is enough
to make proper support anyway.
That said I continue to be mystified over how much effort the external
module people put into avoiding using kbuild.
I have even seen external modules that mixed up proper kbuild
supported modules and old 2.4 style modules in the same Makefile.
And the effort trying to deal with vermagic stuff in external modules,
inspecting CFLAGS setting etc. is just countless :-(
But that does not change my point about giving these people a proper
warning in at least one kernel release.
Sam