linux-kernel - Re: Slow DOWN, please!!!

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: <20080501021327.GS29330@cs181133002.pp.htv.fi>
Date:	Thu, 1 May 2008 05:13:27 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, rjw@...k.pl,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!

On Wed, Apr 30, 2008 at 06:25:50PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 1 May 2008, Adrian Bunk wrote:
> > 
> > One big problem I see is Linus wanting to merge all drivers regardless 
> > of the quality.
> 
> That's not what I said.
> 
> What I said was that I think we get *better* quality by merging early.
> 
> In other words, you're turning the whole argument on its head, and 
> incorrectly so.
> 
> I claim that you are the one that is arguing for *worse* quality, by 
> arguing for a process that is KNOWN to tend to generate bad code 
> (out-of-tree drivers) as opposed to one that tends to fix things over time 
> (and note the "tends" in both cases - there are counter-examples, but 
> the trend is so clear that anybody who disputes it would seem to be either 
> blind or lying).
>...

I am *not* saying it should have stayed out-of-tree.

I am saying that it was merged too early, and that there are points that 
should have been addressed before the driver got merged.

Get it submitted for review to linux-kernel.
Give the maintainers some time to incorporate all comments.
Even one month later it could still have made it into 2.6.25.

The only problem with my suggestion is that it's currently pretty random 
whether someone takes the time to review such a driver on linux-kernel.

And even if I'm getting fire for this again (and different from newbies 
running checkpatch on the kernel) for driver submissions it actually 
makes sense to tell the submitter to fix the checkpatch errors [1], and 
it would have made the driver better in this case (again, it could still 
have made it into 2.6.25).

People are actually more motivated to fix their code for getting it into 
the kernel than to fix their code after it went into the kernel, so we 
might get better quality when merging a bit later.

> 			Linus

cu
Adrian

[1] not necessarily all checkpatch warnings

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/