linux-kernel - Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

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: <1255097287.2934.21.camel@localhost.localdomain>
Date:	Fri, 09 Oct 2009 09:08:07 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Theodore Tso <tytso@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jing Huang <huangj@...cade.com>
Subject: Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

On Fri, 2009-10-09 at 11:15 +0200, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Thu, 8 Oct 2009, Theodore Tso wrote:
> > > 
> > > So would it be acceptable to merge the 50 kloc of crap _during_ the
> > > merge window?
> > 
> > Yes. I actually looked at the driver (since I had pulled it - I've 
> > unpulled it but am still mulling it over), and while I think it looked 
> > huge and overly complex, it by no means gave me the kinds of vibes I 
> > get from some "obviously-ported-from-windows-with-no-clue" drivers.
> > 
> > So at least from my quick look I didn't get the feeling that the 
> > driver was "evil". For me, it's a timing issue.  I hate getting big 
> > pull requests after -rc1 is out, and I really don't like the feeling 
> > that people are just ignoring the merge window.
> > 
> > That said, if somebody wants to look more closely at the driver, and 
> > then wants to convince people that it should have gone through 
> > "staging", feel free. But that's not what I've personally been arguing 
> > about.
> 
> Greg, what's your take on the quality of this new driver? Do you have 
> some time to do a review of this with drivers/staging/ versus drivers/ 
> glasses on? The Git URI is at:

To me, the matter of staging versus actual tree isn't a quality issue
(otherwise we'd be shifting ~75% of SCSI drivers to staging, depending
on whose view of "quality" was being used).  It's an ABI issue.  If we
would have to change the user visible ABI while the driver was being
cleaned up, I'd want it in staging to warn users to expect these
problems.  Although we couldn't clean up everything, I did make sure
this driver plugs correctly into the standard linux FC ABI before
putting it in the SCSI tree, so there are no ABI changes anticipated
even though there will likely be a lot of code changes.  Therefore, the
correct clean up path for this one is through the SCSI tree.

James


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