public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Dave Jones <davej@redhat.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: another attempt to kill off linux/config.h
Date: Wed, 4 Oct 2006 20:26:55 +0200	[thread overview]
Message-ID: <20061004182655.GA9847@uranus.ravnborg.org> (raw)
In-Reply-To: <20061004180122.GC13079@redhat.com>

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

      reply	other threads:[~2006-10-04 18:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-04  7:44 another attempt to kill off linux/config.h Dave Jones
2006-10-04 11:24 ` Sam Ravnborg
2006-10-04 11:45   ` Arjan van de Ven
2006-10-04 18:01     ` Dave Jones
2006-10-04 18:26       ` Sam Ravnborg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061004182655.GA9847@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox