Messages in this thread | | | Date | Fri, 3 Jul 2009 17:11:17 +0100 | From | Alan Cox <> | Subject | Re: [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 staging.
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 bugs.
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 style.
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.
Alan
| |