lkml.org 
[lkml]   [2001]   [Dec]   [29]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: State of the new config & build system
FromMiles Lane <>
Date28 Dec 2001 23:42:17 -0800
On Fri, 2001-12-28 at 22:59, Nicholas Knight wrote:

<snip>

> > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > flexible and accurate than 2.4, including features that lots of
> > people want, like separate source and object trees.  Now that the
> > overall kbuild design is correct, the core code can be rewritten for
> > speed. And that will be done a couple of weeks after kbuild 2.5 goes
> > into the kernel, then I expect kbuild 2.5 to be faster than kbuild
> > 2.4 even on full builds.
> >
> 
> What, exactly, is the point of merging something that nobody is going 
> to use unless they want to test it, in which case they can grab a patch 
> from somewhere?

You don't seem to be reading Keith's message.

The point of merging is that Keith needs time to fix the 
performance problem.  Plus, additional testing would probably 
be helpful.

> It's half the speed of the current system. The current system works, no 
> matter how horrible its internals can be. That makes the NEW system 
> BROKEN. 

No, it's known to be slow in some circumstances.

> If it's KNOWN to be BROKEN prior to merge then it shouldn't 
> even be in a 2.5.*-pre#.

Uh, many drivers cannot be built in the current 2.5 tree.  
Temporary brokenness is acceptable in the development tree.  
It is meant to be _unstable_.  I recall periods when the 
2.3 kernel was corrupting data for many users.  This period
lasted about a week, IIRC.  The kbuild 2.5 system will slow 
people down, but not hose their development system installations.
I personally think two weeks of working at a slower pace is 
an acceptable trade-off for the longterm benefits that Keith
has mentioned.  It seems odd that several people in this
discussion seem to have ignored the repeated statements that
Keith will have little time for dealing with the performance
rewrite until the multiple kernel tree synchronization 
time sink goes away.  Telling Keith that he needs to go on
spinning his wheels while he cannot find time to deal with
the problem you are asking him to fix seems sort of unhelpful.
Perhaps you'd be willing to assist him in the rewrite?

	Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:14    [from the cache]
©2003-2008