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

[Linus Torvalds <torvalds@linux-foundation.org>]

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