LKML Archive on
help / color / mirror / Atom feed
From: Andrea Arcangeli <>
To: Keith Owens <>
Subject: Re: [patch] 2.4.11-pre4 remove spurious kernel recompiles
Date: Mon, 8 Oct 2001 05:07:53 +0200	[thread overview]
Message-ID: <20011008050753.V726@athlon.random> (raw)
In-Reply-To: <20011008041215.O726@athlon.random> <>
In-Reply-To: <>; from on Mon, Oct 08, 2001 at 12:49:25PM +1000

On Mon, Oct 08, 2001 at 12:49:25PM +1000, Keith Owens wrote:
> On Mon, 8 Oct 2001 04:12:15 +0200, 
> Andrea Arcangeli <> wrote:
> >On Mon, Oct 08, 2001 at 11:34:04AM +1000, Keith Owens wrote:
> >The main thing I like is to be able to compile out of the tree and
> >avoiding touching the header files during compilation (that's really
> >annoying).
> All fixed in kbuild 2.5.

Of course I know, this is why I mentioned it :) That's most exiting
thing from my point of view.

> >I personally don't care about correctness in the sense of getting "make"
> >doing everything for you regardless of what you changed, I'm fine with
> >some "make distclean" forced checkpoint after PATCHLEVEL changed etc...,
> >you said infact full compile is needed sometime, not to tell about
> >kernel configuration.
> Strongly disagree.  One of the biggest problems with kbuild is the user
> who applies a patch and expects the kernel to automatically rebuild
> just the bits that are affected.  We must not rely on every user doing
> make distclean or mrproper after applying a patch, we know that does
> not happen, resulting in inconsistent kernels.  If you want to do a
> complete recompile after a patch that is your choice, but we cannot

As everybody out there I have to evaluate every time if a recompile is
needed or not in function of the patch. Not a big deal.

But for mixed collection of patches like pre-patches or -ac, I don't
care, I just recompile the whole thing since it's unlikely I can trust
the build system to do everything right (mkdep problem for example) and
there are usually too many changes to save a rasonable amount of
compile time anyways.

> rely on the entire user population doing that.  kbuild must be
> automatic and correct.

If it's fast as well I'm fine of course :) But waiting the double of the
time isn't an obvious improvement for me, note that when the SUBLEVEL
changes all modules have to be recompiled at least, and so the smarter
buildsystem cannot take advantage of the fact the module sourcecode
didn't changed, and a small change in the include files can have a large
impact of the rebuild percentage etc...

> >One good example is the mkdep hack, it's far from correct: the header
> >dependences is nearly random.  We cannot trust it unless we remeber
> >every user included us (one more reason I'm used to full recompiles),
> Absolutely agree.  The design assumption for mkdep is that the source
> and/or .config do not change after make dep.  That might have been true
> once but with several kernel trees, separate arch patches, separate sub
> system patches and compiling for multiple configurations it is not true
> now.  kbuild 2.5 completely redesigned the dependency tree and gets it
> right!

The mkdep logic (seen as "not going deeper than the explicit #include")
is quite orthogonal with the separate tree issue, you could build the
current .depend tree outside the kernel source tree too, that wouldn't
be a problem.

> However we are getting off the original patch which removes spurious
> compiles from the existing system.

Indeed :).


  reply	other threads:[~2001-10-08  3:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-07 10:25 [patch] 2.4.11-pre4 remove spurious kernel recompiles Keith Owens
2001-10-07 18:05 ` Andrea Arcangeli
2001-10-07 18:16   ` Jeff Garzik
2001-10-07 23:29     ` Keith Owens
2001-10-08  0:05       ` Andrea Arcangeli
2001-10-08  0:42         ` Keith Owens
2001-10-08  1:20           ` Andrea Arcangeli
2001-10-08  1:34             ` Keith Owens
2001-10-08  2:12               ` Andrea Arcangeli
2001-10-08  2:49                 ` Keith Owens
2001-10-08  3:07                   ` Andrea Arcangeli [this message]
2001-10-08 17:56               ` bill davidsen
2001-10-08 16:19 ` bill davidsen

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:

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

  git send-email \
    --in-reply-to=20011008050753.V726@athlon.random \ \ \ \

* 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).