linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "David S. Miller" <davem@redhat.com>
Cc: bunk@fs.tum.de, acme@conectiva.com.br, netdev@oss.sgi.com,
	pekkas@netcore.fi, lksctp-developers@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: [2.6 patch] disallow modular IPv6
Date: Tue, 30 Sep 2003 11:02:49 +0100	[thread overview]
Message-ID: <1064916168.21551.105.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <20030930022410.08c5649c.davem@redhat.com>

On Tue, 2003-09-30 at 02:24 -0700, David S. Miller wrote:
> I think they are the same.  It's module building depending upon the
> kernel image being up to date.
> 
> modules: vmlinux image
> 	... blah blah blah
> 
> or however you want to express it in the makefiles.

In the case of modversions, we are talking about the fact that it may be
physically _impossible_ to build a module referencing an in-kernel
symbol, if the checksum required for that symbol -- the 'version string'
-- is not yet calculated. If the version strings are generated as a
side-effect of compiling the files which actually export the symbols in
question, then it's necessary to do that before building any module
which attempts to use those symbols.

Note that it's not actually necessary to provide a vmlinux file, nor to
do any linking. It's only necessary to perform those steps which produce
the version strings for those symbols actually referenced by the modules
which are being built.

That is the requirement for correctness from the makefiles; nothing
more. Of course it's usually considered acceptable for the makefiles to
recompile _more_ than is necessary, so your way of expressing it above
could indeed be a first, extremely suboptimal, attempt at a 'fix' if the
build is indeed currently broken in the way that you suggest.

> I don't see how this changes the argument I'm trying to make.
> 
> I'm saying that either you accept that the kernel image must be
> uptodate in order to build modules, or you don't.  It doesn't matter
> what creates that dependency.

I agree with your assertion -- it is true that I either accept that fact
or I don't. 

Furthermore, I agree that if it is physically necessary for the kernel
image to be up to date in order to build modules, then it would be a bug
for the build system not to do so. 

That is all irrelevant to the question which started this thread though.
That would be correctly stated as follows:

I am saying that even if I run 'make all', I do not accept that the
resulting kernel image should be _different_ when I change any option
from 'n' to 'm'.

-- 
dwmw2


  parent reply	other threads:[~2003-09-30 10:02 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-28 22:59 RFC: [2.6 patch] disallow modular IPv6 Adrian Bunk
2003-09-28 23:18 ` Arnaldo Carvalho de Melo
2003-09-28 23:24   ` Adrian Bunk
2003-09-28 23:39     ` Arnaldo Carvalho de Melo
2003-09-28 23:47       ` Arnaldo Carvalho de Melo
2003-09-29  0:14       ` Adrian Bunk
2003-09-29  0:32         ` Arnaldo Carvalho de Melo
2003-09-29  9:02           ` David Woodhouse
2003-09-29 14:15             ` Arnaldo Carvalho de Melo
2003-09-29 14:28               ` Jan Evert van Grootheest
2003-09-29 14:29               ` David Woodhouse
2003-09-29 14:38               ` Valdis.Kletnieks
2003-09-29 14:46                 ` David Woodhouse
2003-09-30  5:17             ` David S. Miller
2003-09-30  6:31               ` David Woodhouse
2003-10-01 19:47                 ` Guennadi Liakhovetski
2003-09-30  5:11           ` David S. Miller
2003-09-30 13:37             ` Adrian Bunk
2003-09-30 15:04               ` Arnaldo Carvalho de Melo
2003-10-01  6:39                 ` David S. Miller
2003-09-30  5:09     ` David S. Miller
2003-09-30  6:32       ` David Woodhouse
2003-09-30  7:03         ` David S. Miller
2003-09-30  7:39           ` David Woodhouse
2003-09-30  8:08             ` David S. Miller
2003-09-30  8:26               ` David Woodhouse
2003-09-30  8:30                 ` David S. Miller
2003-09-30  8:42                   ` David Woodhouse
2003-09-30  8:51                     ` David S. Miller
2003-09-30  9:14                       ` David Woodhouse
2003-09-30  9:17                         ` David Woodhouse
2003-09-30  9:24                         ` David S. Miller
2003-09-30  9:57                           ` Sam Ravnborg
2003-09-30 10:02                           ` David Woodhouse [this message]
2003-09-30 10:01                             ` David S. Miller
2003-09-30 10:14                               ` David Woodhouse
2003-09-30 11:39                             ` Sam Ravnborg
2003-09-30 13:44                           ` Dana Lacoste
2003-09-30 13:50                           ` Kai Germaschewski
2003-09-30 15:13                   ` Richard Guy Briggs
2003-09-30 14:21                 ` Theodore Ts'o
2003-09-30 14:51                   ` David Woodhouse
2003-09-30 12:06               ` Olivier Galibert
2003-09-29  6:29 ` Pekka Savola

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=1064916168.21551.105.camel@hades.cambridge.redhat.com \
    --to=dwmw2@infradead.org \
    --cc=acme@conectiva.com.br \
    --cc=bunk@fs.tum.de \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=netdev@oss.sgi.com \
    --cc=pekkas@netcore.fi \
    /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;
as well as URLs for NNTP newsgroup(s).