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]

Date:	Fri, 3 Jul 2009 17:26:51 +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

> Another question: i'm wondering why you brought up Voyager support 
> here. Are you trying to insult me?

[and]

> Pointing out when your code is unclean does not count as an offense 
> on lkml, i hope

Nor then I trust does pointing out that voyager needs a bit of work ;)

I've no objection to pointing out unclean code (or to patches). If
someone wants to fix all the printk(KERN_ calls in the tty layer for for
it - great newbie project if a bit tedious I'd be delighted to receive the
patches.

I'm still however utterly incredulous that you'd look at that bit of
proposed code and see a formatting glitch but not that fact it couldn't
possibly work. I'm still glad you did look at it - don't get me wrong.

The way the tty layer work is done is like this and has been for almost
two years

	- Identify whats the next best thing to tackle on the giant pile
	  of sucky turd list
	- Rework it
	- Debug it
	- If it makes that piece of the code completeish whack the entire
	  file through the coding style process (eg
	  fe9cd962a62cb5f666cf48b9941d3f3cde134254,
	  fb100b6ea7bf8a95e52b90cc0dc0ea5744a0a40a etc)
	- Whines about > 80 characters get ignored
	  for text strings

That not only makes it easier to keep consistent internal styles, merge
patches without collision and keep code and style changes apart it means
that stuff gets cleaned up that doesn't otherwise change.

A good example of what happens if you don't is

scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c

where the core part of the code isn't changed very much even though the
interfaces completely get reworked. Thus it never gets cleaned up and
reviewed as a whole. The code works, will probably work for years but
never gets looked at as a whole and tidied.

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/