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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 3 Jul 2009 18:24:43 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] vt: add an event interface

* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > 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 ?

Clean code is one that is not unclean. Unclean code is for example 
one that does:

+       if( tty->count == 1 && port->count != 1) {

and you pushed that piece of code upstream, and you called 
checkpatch a religion - so apparently you were not using that tool 
and apparently you think it's fine to push such changes upstream.

I.e. your action proves that you are willing to push unclean code, 
and you gave various explanations about why you are not using tools 
that can catch such mistake . Am i allowed to express my 
disagreement with that notion?

> > 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. [...]

But drivers/char/ is not in drivers/staging/, is it?

If you cite drivers/staging/ an argument to introduce unclean code 
into core pieces of Linux then i think you are dead wrong ...

Yes, any textual guide about code is pretty much by definition just 
a guide - to be overruled by common sense as usual.

And i dont think there exists a valid interpretation that says that 
this introduction of unclean code:

$ git log -p -1 a6614999e800cf3a134ce93ea46ef837e3c0e76e | grep -iE 'if.*tty->count'
-       if (tty->count == 1 && port->port.count != 1) {
-       if (tty->count == 1 && port->count != 1)
-	if ((tty->count == 1) && (info->port.count != 1)) {
-       if ((tty->count == 1) && (port->port.count != 1))  {
-       if (tty->count == 1 && port->count != 1)
-       if ((tty->count == 1) && (info->port.count != 1)) {
-       if ((tty->count == 1) && (info->port.count != 1)) {
-	if ((tty->count == 1) && (info->port.count != 1)) {
+       if( tty->count == 1 && port->count != 1) {

was warranted by any common-sense argument. You changed well-working 
code into something different (and unclean) and you - as you have 
repeatedly pointed it out in this thread - disagree with using 
checkpatch - why? It makes no technical sense.

Yes, it's all a minor issue in the end - but you chose to argue 
about the technical review feedback (which i still consider 
correct), not me.

	Ingo
--
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/