Re: [ck] Re: -mm merge plans for 2.6.23

[david@lang.hm]

On Thu, 26 Jul 2007, Jeff Garzik wrote:

> david@lang.hm wrote:
> >  On Thu, 26 Jul 2007, Jeff Garzik wrote:
> >
> > >  Dirk Schoebel wrote:
> > > >   as long as the maintainer follows the kernel development things can 
> > > >   be
> > > >   left in, if the maintainer can't follow anymore they are taken out 
> > > >  quite
> > > >  fast again. (This statement mostly counts for parts of the kernel 
> > > >  where a
> > > >  choice is possible or the coding overhead of making such choice 
> > > >  possible
> > > >   is quite low.)
> > > 
> > > 
> > >  This is just not good engineering.
> > > 
> > >  It is axiomatic that it is easy to add code, but difficult to remove 
> > >  code. It takes -years- to remove code that no one uses.  Long after the 
> > >  maintainer disappears, the users (and bug reports!) remain.
> >
> >  I'll point out that the code that's so hard to remove is the code that
> >  exposes an API to userspace.
>
> True.
>
>
> >  code that's an internal implementation (like a couple of the things being
> >  discussed) gets removed much faster.
>
> Not true.  It is highly unlikely that code will get removed if it has active 
> users, even if the maintainer has disappeared.

if you propose removing code in such a way that performance suffers then 
yes, it's hard to remove (and it should be).

but if it has no API the code is only visable to the users as a side 
effect of it's use. if the new code works better then it can be replaced.

the scheduler change that we're going through right now is an example, new 
code came along that was better and the old code went away very quickly.

the SLAB/SLOB/SLUB/S**B debate is another example. currently the different 
versions have different performance advantages and disadvantages, as one 
drops behind to the point where one of the others is better at all times, 
it goes away.

> The only things that get removed rapidly are those things mathematically 
> guaranteed to be dead code.
>
> _Behavior changes_, driver removals, feature removals happen more frequently 
> than userspace ABI changes -- true -- but the rate of removal is still very, 
> very slow.

a large part of this is that it's so hard to get a replacement that works 
better (this is very definantly a compliment to the kernel coders :-)



> It is axiomatic that we are automatically burdened with new code for at 
> least 10 years :)  That's what you have to assume, when accepting 
> anything.

for userspace API's 10 years is reasonable, for internal features it's 
not. there is a LOT of internal stuff that was in the kernel 10 (or even 
5) years ago that isn't there now. the key is that the behavior as far as 
users is concerned is better now.

David Lang
-
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/