lkml.org 
[lkml]   [2009]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-10-18 23:28    [W:0.383 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site