Re: [PATCH for mm] Remove iBCS support

[Adrian Bunk]

On Fri, Jan 25, 2008 at 04:25:24AM +1030, David Newall wrote:
> Adrian Bunk wrote:
> > Removing dead code makes:
> > - the kernel smaller,
> > - the kernel faster and
> > - makes it easier to maintain the non-dead code.
> 
> The performance benefit is trivial, and the improvement to
> maintainability is even less.

The effects become bigger when you realize that there are many such 
places in the kernel.

And the benefit of keeping it is zero.

Even in the hypothetical case that someone would use it, he could simply 
re-add it.

> > All of these are considered useful by the people who actually 
> > contribute to the Linux kernel.
> 
> Contributions to the kernel take forms other than just code.  I'm
> contributing in this very instance by putting the argument against
> removal of code.  Once removed it'll be much harder to re-insert than to
> repair in-situ.

What you are doing is not contributing but wasting other people's time.

The only thing you could ever achieve with this kind of "contribution" 
is to end up in some killfiles.

> >> At one stage iBCS2 support DID work.  Now it doesn't.  Now there's an
> >> argument that the remaining infrastructure should be removed.  This is
> >> the wrong direction to take.
> >>     
> >
> > When did iBCS2 support work in a plain ftp.kernel.org kernel?
> >   
> I don't know when.  Are you disputing that it ever did?  I think it's a
> given that once it worked.

AFAIK the kernel never shipped with iBCS2 support.

Which kernels under ftp://ftp.kernel.org/pub/linux/kernel/v*.*/ fulfill 
your claim?

> > And if you consider iBCS2 support that important I can only repeat that 
> > the language on Linux kernel are patches, not hot air.
> 
> Fools believe that code is the only acceptable offering, and you, by
> reputation, are not a fool.  There are plenty of examples where
> suggestions made on list have value far exceeding a lot of the code. 
> For that matter, some of the code that's offered is crap.  For that
> matter, good contributed code too often (and in some cases famously)
> gets ignored or rejected for reasons of ego.  You diminish yourself by
> implying that code is the only thing that matters, and present the
> impression that you know little about good development practice, in
> which design effort exceeds that of coding.  I do not believe you are a
> cowboy; stop talking like one.
> 
> Look at the merits of iBCS2 support.  Is it desirable?  Yes.  Is it
> useful to remove what support remains?  Not particularly.  Does it
> improve performance?  Trivially; almost immeasurably.   Does it improve
> clarity?  No.  Does the code serve any useful purpose?  Yes, by acting
> as a reminder of work still be done.  It's like the /* XXX */ comments
> that are widely sprinkled through the system, only more concrete.  The
> benefits of removing it do not outweigh the benefits of leaving it.

The point is that ideas do not turn themselves into code.

And there are far too many people who want to see their great ideas 
implemented without implementing it themselves.

Talking about a feature without having anyone willing to implement it 
simply has no value.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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