Messages in this thread | | | Date | Fri, 3 Jul 2009 17:26:51 +0100 | From | Alan Cox <> | 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
| |