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: <20090703184124.GA4085@elte.hu>
Date:	Fri, 3 Jul 2009 20:41:24 +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:

> > +       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.
> 
> The discussion started about something else - a piece of 
> non-compilable proposal code you space reviewed and didn't even 
> notice wasn't compileable or sane.
> 
> I'm sort of amused you went back through my commits to find that 
> example, and its certainly one that should have been fixed in the 
> final submit. I can't be bothered to write a perl script to 
> checkpatch all your commits and I suspect they all pass anyway.

FYI, it took me less than 10 seconds to find that commit, i didnt 
have to go to any trouble or perl script - i just searched for the 
same bad pattern i saw here.

You should consider putting in some automation into your workflow if 
you have some time - it really helps. I was surprised how much 
easily fixable crap various measures of automation found in my own 
patches. The tools are there to use them, not to ignore, ridicule or 
fight them, and for kernel oldbies there's absolutely no valid 
excuse to not use them IMHO.

It's a bit sad you are making such a big deal out of my criticism 
though. Your criticism about the x86/MTRR code was spot on, mind 
doing some more review on arch/x86/?

	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/