The continuing saga of kbuild 2.5. [LWN.net]

The discussion over whether to merge kbuild 2.5 has been covered in this space before. It is one of those conversations that persists, however. A few things have happened over the last few weeks.

Keith Owens, the author of kbuild 2.5, has posted a new set of timing comparisons meant to show the advantages of the new code. The full build process Keith performed took a bit less than 14 minutes with kbuild 2.5, and a little over 20 minutes with the existing kbuild. He also points out that the result is sometimes incorrect with the existing code.

Daniel Phillips also tried it out and obtained similar results. For good measure, Daniel took a look at the code itself: "There is no Python anywhere to be seen in kbuild 2.5, for those who worry about that. It is coded in C, about 10,000 lines it seems. It has a simple built in database which I suppose accounts for some of that. For what it does, it seems quite reasonable."

In general, most (but not all) developers who express an opinion on the matter seem to feel that kbuild 2.5 is worthwhile and should be merged. So it has surprised a number of people to see numerous patches to the existing kbuild system, written by Kai Germaschewski, being merged by Linus. These patches do worthwhile things, but they are not kbuild 2.5. Why bother, one might ask, if the whole thing is going to be replaced?

The answer seems to be that Linus, for now, wants Kai to be the kbuild maintainer. Kai is willing to do things in small pieces, which has always been Linus's preferred method; Keith has, so far, refused to break his kbuild work up in this way. Also, says Linus:

Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends to be a bit down on some of it. Which is a plus in my book: it means that whatever Kai tries to push my way I'll feel just that much more comfortable with as having had critical review.

Meanwhile, a couple of different developers (Sam Ravnborg and "Lightweight patch manager") have started submitting broken up versions of kbuild 2.5. Kai has stated that he will look them over and integrate those which make sense. Some of these patches also found their way into 2.5.20-dj3. It seems like at least a partial victory for the new kbuild.

So one has to wonder why, after all this, Keith felt the need to post his call for an email campaign entitled "If you want kbuild 2.5, tell Linus." It's a full-scale polemic that takes one back to the old devfs wars. It is also, seemingly, counterproductive. One would think that would be better to work with the people who are trying to make kbuild acceptible to Linus than to call for a pressure campaign.

to post comments

I can understand his frustration

Posted Jun 6, 2002 18:29 UTC (Thu) by Shamgar (guest, #1356) [Link]

While I'm not a kernel developer I have faced situations where someone gives you positive feedback on an idea, and agreement to implement. Then you go and put all kinds of time and effort into the project to meet your end of the bargain only to have the other guy drop the ball and blow you off.

This is not a pleasant thing. Obviously, I am not either of these guys, so I can't presume to know the details, but there is a fair amount of evidence from lwn's own archives on this topic to support his position on this. It is made even worse in that this is a volunteer effort. (Unless Keith is getting paid for this. He could be for all I know). Maintaining this new build across releases while Linus makes up his mind and ignores his emails just adds to his frustration I imagine.

I understand and respect Linus' desire to avoid "flag days". However, I think Keith has made a very good case for this one. More than that, it co-exists with the existing code, so it isn't like it runs a high risk of breaking the build system entirely, as the old system will still work fine alongside it. I'm don't know what Linus' true reasons are for taking this tack, but from where I sit it looks rather silly to me.

Why kbuild 2.5 needs to go in as one change

Posted Jun 7, 2002 6:37 UTC (Fri) by DeletedUser1711 ((unknown), #1711) [Link]

"Keith has, so far, refused to break his kbuild work up in this way" is not correct. Read my mail, in particular Q16 and Q17. If somebody comes up with a sensible way of applying the patches a bit at a time then I will listen, but nobody who really understands the problem thinks that this is doable.

Sending multiple patches, only one of which does anything is not the answer. Linus said

where "gradual" really means that features are added one-by-one (and that does _not_ mean "build up the infrastructure slowly, so that the final 'flag-day' patch itself is small but has large ramifications")

In the case of kbuild 2.5, there is no useful overlap between the old and new systems, it is a complete replacement. Hence the need for all the code to go in together.

What Kai is doing is NOT kbuild 2.5. Instead he is fiddling with the existing system, taking the fixes for the easy problems from kbuild 2.5 and ignoring the hard problems. At best this will result in a pale imitation of kbuild 2.5, with fewer features. At worst it will be a continutation of all the build problems that have plagued the kernel for years.