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]

Date:	Thu, 8 Oct 2009 13:25:20 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...e.de>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

On Thu, 8 Oct 2009, James Bottomley wrote:
> 
> OK, you're saying the merge window exemption should only apply to
> drivers which meet our coding standards.

Well, to me, it's not even "coding standards". It's more about "letting 
things slide so that users get their hands on things earlier, since it 
can't really regress". Coding standards are obviously a part of that, but 
I think the coding standard question should come into this mainly in the 
sense of "should it go through staging or not" kind of sense, not in the 
timing sense.

The reason I object to this driver at this point is that I really think 
there's a _huge_ difference between some random average driver, and a 50 
kloc monster driver that basically seems to implement its own protocol.

Most random new drivers tend to be a few hundred lines of code, in some 
cases a few thousand. They don't generally bring in their own subsystem 
code, they often just hook into existing things like the libata layer or 
the network driver infrastructure etc.

So most drivers are in a totally different class than the one I'm 
objecting to in the SCSI tree.

And I also really do think there is a huge difference between some 
specialized high-end SCSI driver that is only relevant to enterprise 
people and some more average driver that is expected to perhaps exist in 
lots of consumer devices. How many people does it affect, and what's their 
ability to handle it?

Another way of putting that "consumer" vs "enterprise" thing: how big is 
the _upside_ of merging the driver outside fo the merge window? Again, I 
simply think pure number of potential users matters for the "should we let 
it slide" question.

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