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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 26 Jul 2007, Jeff Garzik wrote:

[email protected] 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux