linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Germaschewski <kai.germaschewski@unh.edu>
To: "David S. Miller" <davem@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>, <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 09:50:14 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0309300940030.4956-100000@chaos.sr.unh.edu> (raw)
In-Reply-To: <20030930022410.08c5649c.davem@redhat.com>

On Tue, 30 Sep 2003, 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.

I strongly disagree with this. What the makefiles currently do is correct, 
i.e. if you "make modules" you'll only get updated modules, you didn't ask 
for an updated vmlinux, and so you don't get it. The module you get is 
built correctly, i.e. you'd get the same result if you had rebuilt vmlinux 
before, since the building of the module does not depend on a "correct" 
vmlinux at all.

If in just about any project you type "make some_object.o", you don't 
expect make to recompile and rebuild the rest of the project, either, you 
ask it to 'make' something, and will build exactly that something and the 
prerequisites necessary to get it right.

A sidenote is that if you are using modversions, building the modules
correctly needs versioning information from vmlinux, so in that case we
need vmlinux to be up-to-date. And that's why in this case vmlinux will be
rebuilt first (if something changed) - otherwise the modules you were
asking for wouldn't be correct. But the fact the you get an updated
vmlinux is just a side-effect, you didn't ask for it, and thus you can't
rely on it.

Think about the meaning of "make".


With respect to the actual discussion, my opinion is that it's desirable 
to have the core kernel not change depending on whether or not something 
is compiled modular, but I believe there are cases which justify an 
exception, and IPv6 seems to be one of them. Modversions will catch this
and prevent the user from inserting the module and accidentally crash the 
system, so I think it's all fine.


--Kai



  parent reply	other threads:[~2003-09-30 13:53 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
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 [this message]
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=Pine.LNX.4.44.0309300940030.4956-100000@chaos.sr.unh.edu \
    --to=kai.germaschewski@unh.edu \
    --cc=acme@conectiva.com.br \
    --cc=bunk@fs.tum.de \
    --cc=davem@redhat.com \
    --cc=dwmw2@infradead.org \
    --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).