The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: fault.c cleanup, what else could it be
Date: Tue, 31 Mar 2009 02:16:16 +0400	[thread overview]
Message-ID: <20090330221616.GA28060@x200.localdomain> (raw)
In-Reply-To: <20090330014926.GA32139@elte.hu>

On Mon, Mar 30, 2009 at 03:49:26AM +0200, Ingo Molnar wrote:
> 
> * Al Viro <viro@ZenIV.linux.org.uk> wrote:
> 
> > On Mon, Mar 30, 2009 at 03:13:55AM +0200, Ingo Molnar wrote:
> > 
> > > There is simply no excuse for ever having let that crap get there 
> > > into fs/proc/base.c. There is no excuse for ever letting that crap 
> > > grow. The fact that that crap is there is proof of systemic failure 
> > > over the years to keep that code clean.
> > 
> > Nothing like proof by assertion, eh?
> 
> The proof is what i quoted - see below the full dump again. Those 
> are bona fide evidence of unclean code.
> 
> > > I dont really want to see "real work" done on code that was not 
> > > properly and cleanly finished in the first place.
> > 
> > Tough.  At the moment we have a rather unpleasant hole with 
> > tentative fix that touches fs/proc/base.c.  Whether you want said 
> > work postponed until all whitespace wanking is done on file in 
> > question or not, I simply don't give a damn - getting rid of real 
> > bug takes precedence.  Whitespace crap should be dealt with as we 
> > go through the functions containing such crap, religious bullshit 
> > nonwithstanding.
> 
> I am profoundly surprised that something as lightweight and simple 
> as a cleanup patch can make life difficult to you at all. How are 
> you handling them? Have you ever tried?
> 
> > And I very much object against completely unfounded assertions 
> > claiming that checkpatch noise makes a useful proxy for code 
> > quality.  You keep making those again and again, without a shred 
> > of evidence to show.
> 
> You dont have to take my word for it. Look at the output below. 
> Check the code. Compare to the CodingStyle. If it does not match, 
> then it's unclean code that should have been rejected when it got 
> there. Some of that is ancient code, some of that is recent code.
> 
> It might be perfectly fine code otherwise, i made no assertion about 
> the quality of other code in that area.
> 
> 	Ingo
> 
> ---------------->
> ERROR: space required before the open parenthesis '('
> #154: FILE: proc/base.c:154:

I'm finally convinced you do not understand what's going on in this
thread and previous threads on the subject and quitting. There will be
C/R stuff because I already promised and nothing more.

  parent reply	other threads:[~2009-03-30 22:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-29 17:56 fault.c cleanup, what else could it be Alexey Dobriyan
2009-03-29 20:39 ` David Miller
2009-03-29 23:24 ` Ingo Molnar
2009-03-29 23:48   ` Al Viro
2009-03-30  1:13     ` Ingo Molnar
2009-03-30  1:33       ` Al Viro
2009-03-30  1:49         ` Ingo Molnar
2009-03-30  4:25           ` Al Viro
2009-03-30 22:16           ` Alexey Dobriyan [this message]
2009-03-30  0:29   ` Alexey Dobriyan

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=20090330221616.GA28060@x200.localdomain \
    --to=adobriyan@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=viro@ZenIV.linux.org.uk \
    /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