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: <20090703161021.GA21399@elte.hu>
Date:	Fri, 3 Jul 2009 18:10:21 +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:

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