Message-Id: <1255012399.4187.24.camel@mulgrave.site>
Date:	Thu, 08 Oct 2009 14:33:19 +0000
From:	James Bottomley <James.Bottomley@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 Tue, 2009-10-06 at 20:54 +0000, James Bottomley wrote:
> On Tue, 2009-10-06 at 08:58 -0700, Linus Torvalds wrote:
> > 
> > On Tue, 6 Oct 2009, James Bottomley wrote:
> > >
> > > This is mostly fixes.  However, it contains two new drivers: Brocade SAS
> > > (bfa), the Bladengine2 iSCSI (be2iscsi) under the merge window exemption
> > 
> > Btw, I'm getting less excited about the merge window exemption.
> > 
> > It makes sense for consumer devices that people actually hit and that are 
> > needed for bringup (ie they make a difference between a system that can be 
> > installed and used, and one that cannot), but I'm not at all sure it makes 
> > sense for things like this.
> > 
> > The _reason_ for the driver exemption was the fact that even a broken 
> > driver is better than no driver at all for somebody who just can't get a 
> > working system without it, but that argument really goes away when the 
> > driver is so specialized that it's not about regular hardware any more.
> 
> OK, so I don't see a huge distinction here.  This is a driver for a
> piece of enterprise HW that Linux previously didn't support.  To someone
> cursing not being able to use there hardware, it's every bit as
> important as the latest wireless driver.
> 
> > And the whole "driver exemption" seems to have become a by-word for "I can 
> > ignore the merge window for 50% of my code". Which makes me very tired of 
> > it if there aren't real advantages to real users.
> 
> While the exemption exists, I can certainly ignore the merge window for
> new drivers, yes ... however, that's not 50% of the code submitted in
> the merge window, and it's one time ... the same driver follows the
> merge window for the next release.  I try to police this pretty rigidly
> in SCSI ... as you do at the top.
> 
> In fact, for SCSI, these two drivers are the third and fourth merge
> window exemptions in our year long history of allowing this.
> 
> > So I'm seriously considering a "the driver has to be mass market and also 
> > actually matter to an install" rule for the exemption to be valid.
> 
> OK, so on the policy, let me argue against the above.  One of the things
> we've been saying about linux is that we facilitate rapid adoption of
> new hardware (and that we support more hardware than any other OS).  The
> Merge window exemption was adopted at the kernel summit last year
> specifically to speed our adoption of new hardware.  I think it's
> valuable for this speed of adoption to be *all* hardware, not
> specifically mass market laptop type stuff.
> 
> However, even if you want to change the definition, can we please not do
> it retroactively?

So what do you want to do about this?  I need the fixes in this tree to
go forwards even if you don't want the new drivers ... I also now have a
list of other fixes to put in the next round which I'd like to get into
linux-next but while this is unresolved I can't really add more stuff to
my rc-fixes 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/

Powered by blists - more mailing lists