linux-kernel - Re: [PATCH] vt: add an event interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090703171117.574677de@lxorguk.ukuu.org.uk>
Date:	Fri, 3 Jul 2009 17:11:17 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/