kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
I'm not sure I understand what you're saying here. Yes, the build system is mostly the same across all these versions -- that's my point. I want it to STAY the same as long as possible. What's the relationship between kbuild and the size of the kernel source? Are you saying a new build system would make the kernel smaller? Or do you mean that it would be faster, or would require recompiling smaller portions of the kernel after patching? That wouldn't help me, because I'll never trust *any* build system -- even good ol' "make" itself -- to make the right determination of what to recompile after applying one of Linus's or Alan's patch sets. I *always* "make mrproper" and recompile *everything* after patching. (Back in my Minix days I usually didn't stop with recompiling the kernel, but recompiled everything -- libraries, user-space programs like "cat" and "ls," etc. -- after applying patches. Minix upgrades frequently took me 10 hours or more on my 8088 system.) As for speed, my Pentium II laptop compiles 2.5.15 a lot faster than my old 486 desktop compiled 0.99pl13 (my first kernel).
Dave Jones <[email protected]> on 05/17/2002 03:09:22 PM
To: Wayne Brown/Corporate/Altec@Altec
cc: [email protected]
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
Compare and contrast..
-rw-r--r-- 1 davej users 31426560 Jan 9 2001 linux-2.0.39.tar -rw-r--r-- 1 davej users 85442560 Nov 6 2001 linux-2.2.20.tar -rw-r--r-- 1 davej users 131727360 Feb 25 20:15 linux-2.4.18.tar -rw-r--r-- 1 davej users 152524800 May 10 00:11 linux-2.5.15.tar
Spot the pattern? Exponential growth. not only that, but for the most part, the build system is the same across all of these. If we continue growing at the current rate without doing something about the build process, we're all going to be needing 8-way Opterons with several GB of memory to get any work done.
If kbuild2.5 is faster, and produces the same end result (or better still, more accurate builds), there's no valid reason to ignore it that I can see.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 17 lines · [email protected] wrote:
I'm not sure I understand what you're saying here. Yes, the build system is mostly the same across all these versions -- that's my point. I want it to STAY the same as long as possible. What's the relationship between kbuild and the size of the kernel source? Are you saying a new build system would make the kernel smaller? Or do you mean that it would be faster, or would require recompiling smaller portions of the kernel after patching? That wouldn't help me, because I'll never trust *any* build system -- even good ol' "make" itself -- to make the right determination of what to recompile after applying one of Linus's or Alan's patch sets. I *always* "make mrproper" and recompile *everything* after patching. (Back in my Minix days I usually didn't stop with recompiling the kernel, but recompiled everything -- libraries, user-space programs like "cat" and "ls," etc. -- after applying patches. Minix upgrades frequently took me 10 hours or more on my 8088 system.) As for speed, my Pentium II laptop compiles 2.5.15 a lot faster than my old 486 desktop compiled 0.99pl13 (my first kernel).
That's you. On May 15 and May 16 I rebuilt the kernel over 150 times.
The deteriorating performance of gcc and the tendency of the current build system to needlessly recompile stuff are acute problems. ccache saves me probably one hour per day.
-
Quoted 2 lines · Andrew Morton
That's you. On May 15 and May 16 I rebuilt the kernel over 150 times.
Nice build system.
Quoted 3 lines · Andrew Morton
The deteriorating performance of gcc and the tendency of the current build system to needlessly recompile stuff are acute problems. ccache saves me probably one hour per day.
A build on my laptop takes well over an hour. This is not useful for actually getting things done. I'm all for mitigating build time in such cases, by kbuild-2.5 and perhaps other methods.
Cheers,
Bill
Quoted 8 lines · William Lee Irwin III
Quoted 3 lines · Andrew Morton
The deteriorating performance of gcc and the tendency of the current build system to needlessly recompile stuff are acute problems. ccache saves me probably one hour per day.
A build on my laptop takes well over an hour. This is not useful for actually getting things done. I'm all for mitigating build time in such cases, by kbuild-2.5 and perhaps other methods.
I suppose you want ccache then. kbuild-2.5 may save two minutes of your one hour build. The current kbuild's problem is not that it recompiles too many files, but rather too few sometimes (in particular with modversions).
(And yes, ccache won't work too well if you move your trees around, since *both* build systems use absolute paths. That needs fixing)
--Kai
Quoted 7 lines · Kai Germaschewski
Quoted 5 lines · William Lee Irwin III
Quoted 3 lines · Andrew Morton
The deteriorating performance of gcc and the tendency of the current build system to needlessly recompile stuff are acute problems. ccache saves me probably one hour per day.
Quoted 6 lines
Quoted 3 lines
A build on my laptop takes well over an hour. This is not useful for actually getting things done. I'm all for mitigating build time in such cases, by kbuild-2.5 and perhaps other methods.
I suppose you want ccache then. kbuild-2.5 may save two minutes of your one hour build.
That's assuming you have to build from scratch. The whole point is to reduce the need to do that by making dependencies more accurate.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 3 lines · William Lee Irwin III
Quoted 3 lines
A build on my laptop takes well over an hour. This is not useful for actually getting things done. I'm all for mitigating build time in such cases, by kbuild-2.5 and perhaps other methods.
Quoted 5 lines · Kai Germaschewski
I suppose you want ccache then. kbuild-2.5 may save two minutes of your one hour build. The current kbuild's problem is not that it recompiles too many files, but rather too few sometimes (in particular with modversions). (And yes, ccache won't work too well if you move your trees around, since *both* build systems use absolute paths. That needs fixing)
Hmm. That kind of blows. Well, someone else's problem (or is it?). I'll take it for what it can do now and plod along.
Cheers,
Bill
Quoted 9 lines · William Lee Irwin III
Quoted 5 lines · Kai Germaschewski
I suppose you want ccache then. kbuild-2.5 may save two minutes of your one hour build. The current kbuild's problem is not that it recompiles too many files, but rather too few sometimes (in particular with modversions). (And yes, ccache won't work too well if you move your trees around, since *both* build systems use absolute paths. That needs fixing)
Hmm. That kind of blows. Well, someone else's problem (or is it?). I'll take it for what it can do now and plod along.
In the for what it is worth department, we like ccache here at BitMover and converted the CVS tree to BK just for fun.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 10 lines · On Fri, 17 May 2002 [email protected] wrote:
I'm not sure I understand what you're saying here. Yes, the build system is mostly the same across all these versions -- that's my point. I want it to STAY the same as long as possible. What's the relationship between kbuild and the size of the kernel source? Are you saying a new build system would make the kernel smaller? Or do you mean that it would be faster, or would require recompiling smaller portions of the kernel after patching? That wouldn't help me, because I'll never trust *any* build system -- even good ol' "make" itself -- to make the right determination of what to recompile after applying one of Linus's or Alan's patch sets. I *always* "make mrproper" and recompile *everything* after patching.
But even if you recompile *everything* _everytime_, kbuild 2.5 is "faster".
What do you have against that?
Nicolas
Quoted 4 lines · On Fri, 17 May 2002 [email protected] wrote:
That wouldn't help me, because I'll never trust *any* build system -- even good ol' "make" itself -- to make the right determination of what to recompile after applying one of Linus's or Alan's patch sets. I *always* "make mrproper" and recompile *everything* after patching.
And the new kbuild will do that faster - what the problem again? For those of us who actually trust the makefile concept, if not the current makefiles, the new kbuild also happens to be designed to do the right thing after a patch.
More importantly, it makes the make system manageable again.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."