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