mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] vt: add an event interface
Date: Fri, 3 Jul 2009 18:10:21 +0200	[thread overview]
Message-ID: <20090703161021.GA21399@elte.hu> (raw)
In-Reply-To: <20090703143746.0379b2ee@lxorguk.ukuu.org.uk>


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

> [...] Quite frankly the way some people behave with it is a 
> disgrace and it puts people off contributing to the kernel when 
> their 500 line driver gets nothing but emails from people saying 
> "that space is wrong". [...]

I'd like to address your generic argument here because i think it's 
interesting.

The thing is, IMO if the author or the affected maintainer(s) are 
not willing to do _basic_ cleanup of new drivers, they simply dont 
deserve more substantial review.

Why? Because their lack of basic care is a sign that they will 
likely be unwilling to expend the (far bigger) effort of actually do 
ongoing maintenance of the driver.

drivers/isdn/ is one example of unclean code, which, once it got 
upstream, never got cleaned up.

Its also a positive feedback loop: lack of basic cleanups deters 
contributors (for example i personally try to stay away from 'weird 
looking' code as 'not worth the effort'), which makes the code even 
worse ... which then bitrots as kernel facilities slowly change as 
the months go on.

So such unclean drivers you mention above should probably go to 
drivers/staging/ - that is an effort that tries to de-crappify 
drivers before they get mixed into core drivers.

All in one, i dont see at all the harm from people looking at 
stylistic issues first - it's an obvious first easy level of trust 
to inject into an unknown piece of code - if the reply to that 
minimal stylistic review is fixes then it makes sense to inject more 
effort into reviewing the driver. If the reply is defiance or 
inaction then the reviewer probably should not bother because nobody 
cares about his feedback.

Thanks,

	Ingo

  parent reply	other threads:[~2009-07-03 16:10 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-02 11:36 Alan Cox
2009-07-03  6:45 ` Ingo Molnar
2009-07-03  9:08   ` Alan Cox
2009-07-03  9:16     ` Ingo Molnar
2009-07-03  9:44       ` Alan Cox
2009-07-03  9:54         ` Ingo Molnar
2009-07-03 10:06           ` Alan Cox
2009-07-03 10:22             ` Ingo Molnar
2009-07-03 10:44               ` Alan Cox
2009-07-03 13:17                 ` Ingo Molnar
2009-07-03 13:37                   ` Alan Cox
2009-07-03 14:47                     ` Ingo Molnar
2009-07-03 15:02                       ` Alan Cox
2009-07-03 15:42                         ` Ingo Molnar
2009-07-03 15:48                         ` Ingo Molnar
2009-07-03 16:11                           ` Alan Cox
2009-07-03 16:24                             ` Ingo Molnar
2009-07-03 18:29                               ` Alan Cox
2009-07-03 18:41                                 ` Ingo Molnar
2009-07-03 15:57                         ` Ingo Molnar
2009-07-03 15:58                         ` Ingo Molnar
2009-07-03 16:26                           ` Alan Cox
2009-07-03 16:33                             ` Ingo Molnar
2009-07-03 16:42                             ` Ingo Molnar
2009-07-03 22:17                               ` Jaswinder Singh Rajput
2009-07-04  2:18                               ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
2009-07-04  2:20                                 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
2009-07-04  2:20                                   ` [PATCH 2/9 -tip] x86: mtrr/centaur.c fix " Jaswinder Singh Rajput
2009-07-04  2:21                                     ` [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial " Jaswinder Singh Rajput
2009-07-04  2:22                                       ` [PATCH 4/9 -tip] x86: mtrr/cyrix.c " Jaswinder Singh Rajput
2009-07-04  2:23                                         ` [PATCH 5/9 -tip] x86: mtrr/generic.c fix " Jaswinder Singh Rajput
2009-07-04  2:23                                           ` [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial " Jaswinder Singh Rajput
2009-07-04  2:24                                             ` [PATCH 7/9 -tip] x86: mtrr/mtrr.h " Jaswinder Singh Rajput
2009-07-04  2:24                                               ` [PATCH 8/9 -tip] x86: mtrr/state.c " Jaswinder Singh Rajput
2009-07-04  2:26                                                 ` [PATCH 9/9 -tip] x86: mtrr/main.c fix " Jaswinder Singh Rajput
2009-07-05 18:21                                 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
2009-07-05 22:09                                   ` Jaswinder Singh Rajput
2009-07-04 10:06                               ` [tip:x86/cleanups] x86: Clean up mtrr/amd.c: tip-bot for Jaswinder Singh Rajput
2009-07-04 10:06                               ` [tip:x86/cleanups] x86: Clean up mtrr/centaur.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07                               ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
2009-07-04 21:12                                 ` Yinghai Lu
2009-07-05  0:27                                   ` Ingo Molnar
2009-07-05  6:02                                     ` Jaswinder Singh Rajput
2009-07-05 11:59                                       ` Pekka Enberg
2009-07-05 13:19                                         ` Jaswinder Singh Rajput
2009-07-05 20:11                                           ` Thomas Gleixner
2009-07-05 22:16                                             ` Jaswinder Singh Rajput
2009-07-05 18:04                                       ` Ingo Molnar
2009-07-04 10:07                               ` [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07                               ` [tip:x86/cleanups] x86: Clean up mtrr/generic.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07                               ` [tip:x86/cleanups] x86: Clean up mtrr/if.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07                               ` [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08                               ` [tip:x86/cleanups] x86: Clean up mtrr/state.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08                               ` [tip:x86/cleanups] x86: Clean up mtrr/main.c tip-bot for Jaswinder Singh Rajput
2009-07-05  7:57                               ` [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c tip-bot for Ingo Molnar
2009-07-03 16:10                     ` Ingo Molnar [this message]
2009-07-03 18:24                       ` [PATCH] vt: add an event interface Alan Cox
2009-07-21 16:23 ` Lennart Poettering
2009-07-21 16:32   ` Alan Cox
2009-07-22 11:14     ` Lennart Poettering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090703161021.GA21399@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®