lkml.org 
[lkml]   [2009]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: fault.c cleanup, what else could it be
    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.


    \
     
     \ /
      Last update: 2009-03-31 00:11    [W:0.027 / U:0.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site