linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Newall <davidn@davidnewall.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>, Andi Kleen <andi@firstfloor.org>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for mm] Remove iBCS support
Date: Fri, 25 Jan 2008 04:25:24 +1030	[thread overview]
Message-ID: <4798D10C.6090109@davidnewall.com> (raw)
In-Reply-To: <20080124172414.GD4476@does.not.exist>

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.

> 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.

>> 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.

> 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.

  reply	other threads:[~2008-01-24 17:55 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19  4:59 [PATCH for mm] Remove iBCS support Andi Kleen
2008-01-20  2:27 ` David Newall
2008-01-20  3:11   ` Andi Kleen
2008-01-20  4:46     ` David Newall
2008-01-20  5:18       ` Andi Kleen
2008-01-20  5:33         ` David Newall
2008-01-20  5:55           ` Andi Kleen
2008-01-20  6:23             ` David Newall
2008-01-20  7:29               ` Andi Kleen
2008-01-21  1:37                 ` David Newall
2008-01-22 10:24                   ` Karl Kiniger
2008-01-22 15:06                     ` David Newall
2008-01-22 15:52                       ` Adrian Bunk
2008-01-23  8:48                     ` Andi Kleen
2008-01-23 14:12                       ` Karl Kiniger
2008-01-23 14:24                         ` Andi Kleen
2008-01-24 17:06                           ` David Newall
2008-01-22 11:12                   ` Ingo Molnar
2008-01-22 12:42                     ` Karl Kiniger
2008-01-22 15:13                     ` David Newall
2008-01-22 15:49                       ` Ingo Molnar
2008-01-24 17:01                         ` David Newall
2008-01-22 16:01                       ` Adrian Bunk
2008-01-24 17:04                         ` David Newall
2008-01-24 17:24                           ` Adrian Bunk
2008-01-24 17:55                             ` David Newall [this message]
2008-01-24 18:14                               ` Adrian Bunk
2008-01-25  2:14                                 ` David Newall
2008-01-25  5:12                                   ` Valdis.Kletnieks
2008-01-25 16:40                                   ` Alan Cox
2008-01-24 19:51                               ` Pavel Machek
2008-01-25  2:17                                 ` David Newall
2008-01-24 20:37                               ` Andi Kleen
2008-01-25  2:16                                 ` David Newall
2008-01-22 16:50                       ` Alan Cox
2008-01-24 17:08                         ` David Newall
2008-01-22 13:20                 ` Giulio
2008-01-20 13:06           ` Alan Cox
2008-01-20 13:43             ` David Newall
2008-01-20 13:51               ` Alan Cox
2008-01-25 12:17 ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4798D10C.6090109@davidnewall.com \
    --to=davidn@davidnewall.com \
    --cc=akpm@osdl.org \
    --cc=andi@firstfloor.org \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).