[lkml]   [2009]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] vt: add an event interface
    > So did i get you right that in your opinion sending and writing 
    > clean code is a 'bogus standard'? Sorry about trying to interpret
    > you here, i have no choice because you did not reply to my question.

    Your definition of "clean code" being ?

    > I thought the obvious portions of Documentation/CodingStyle applied
    > to everyone - so it applies to you only if you like it?

    CodingStyle is a guide - it applies as a guide to people. It's also lower
    priority than working code. Which is why for example we have staging.
    Linus pretty clearly ruled where the priorities were I think in accepting

    Now my pending queue has a collection of patches that make the
    CodingStyle script whine. I don't care because they improve the cyclades
    driver and they are heading in the right direction. Funnily enough none
    of the vt patches pending make it moan at all having just checkpatched
    them for amusement.

    I have every intention of sending them upstream because the patch author
    has the technical details right, they make the driver better and they fix

    vt has 329 codingstyle complaints. Most of that code hasn't changed in
    years so a policy of pointless macdinking new patches won't change it but
    will mess up the internally consistent style. Instead when vt is settled
    down and cleaned up it can have a single cleanup pass. Which is what
    happened to various of the tty files as they reached that state.

    I could whine about spaces and make the author rewrite them and rework
    them so that they made the cyclades driver suffer random weird changes
    between its format and CodingStyle but would that actually be a
    productive use of anyones time - no.

    I don't care if you want to run a policy where you refuse x86 improvements
    because there is a misplaced space. If it makes you happy so be it. OTOH
    I am not going to drive people away from contributing to the kernel by
    forgetting that CodingStyle is a guide, or that a lot of existing kernel
    code doesn't follow it and is best patched by keeping it in its original

    The other thing CodingStyle is doing now is creating code which is utterly
    crap but passes the CodingStyle file because some poor low paid sod in a
    software shop somewhere has been told to supply a Linux driver that
    passes CodingStyle. Note one that is any good, not one that is following
    any Linux code guidelines, not even one that is tested. Instead its become
    this monster that less Linux literate software businesses are using to
    sign off contracts with in some expectation that "hey it passes
    CodingStyle it'll go in" and get outraged when it's refused.

    If you want to fix the tty layer to be coding style perfect then send
    patches, but there are tons of coding style problems in arch/x86 if you
    feel so strongly about it.


     \ /
      Last update: 2009-07-03 18:13    [W:0.030 / U:3.440 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site