From: Sam Ravnborg <sam@ravnborg.org>
To: kbuild-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
Date: Fri, 15 Feb 2002 22:42:35 +0100 [thread overview]
Message-ID: <20020215224235.A1292@mars.ravnborg.org> (raw)
In-Reply-To: <200202150057.g1F0v8P23914@golux.thyrsus.com> <3C6CE148.5020804@dplanet.ch>
In-Reply-To: <3C6CE148.5020804@dplanet.ch>; from cate@dplanet.ch on Fri, Feb 15, 2002 at 11:22:00AM +0100
On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote:
[Not a single word about the battle ongoing at LKLM...]
> kbuild-2.5:
>
> It does the right things! And this should be enought to tell you that
> it should be included in the next kernels.
When Keith brought up the inclusion of kbuild-2.5 last time the general
statement was that kbuild-2.5 had one fundamental error - speed.
I have tested it a while back, and my result was not as bad as the
roumours said about kbuild-2.5.
Light .config, Pentium 266 with 64 MB RAM.
kbuild-2.4 make dep + make bzImage ~55 minutes
kbuild-2.5 make installable ~60 minutes
Then I added one more driver.
kbuild-2.4 make dep + make bzImage ~7 minutes
kbuild-2.5 make installable ~2 minutes
So my conclusion was that one single change where *I* had to run
make dep made it worthwhile to shift to kbuild-2.5.
I know that *I* have to run make dep far more often than
all the kernel hackes - they know what they are doing in contrast.
With respect to kbuild-2.5 inclusion, I would vote for the distributed
configuration scheme that Linus et al. suggested a while ago.
[driver.conf that included makefile.in, configure.help etc.]
When kbuild-2.5 has been extended to support it, and the link-order
have been solved then it is due time for inclusion.
Jeff Garzik & Keith O. had some discussion about the link-order
problem a while ago, but at that point in time Keith stopped the
discussion whith the statement that he did not care about 2.5,
with reference to the refusual from Linus to accept among others
the LINK_FIRST - LINK_LAST patch.
I dunno what the conclusion on the link-order issue was.
What I read between the lines is that kbuild-2.5 should not only fix
the kbuild-2.4 bugs[*], but should also address the scalability issues
that Linus raised - before he accepts it.
[*] Bugs that I see, but kernel hackers are not hit by - because
they know what they are doing.
Personal I would like to see kbuild-2.5 included ASAP. Among other stuff
I like the compressed output during compilation.
Sam
next parent reply other threads:[~2002-02-15 21:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200202150057.g1F0v8P23914@golux.thyrsus.com>
[not found] ` <3C6CE148.5020804@dplanet.ch>
2002-02-15 21:42 ` Sam Ravnborg [this message]
2002-02-18 13:10 ` Thomas Capricelli
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=20020215224235.A1292@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®