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:	Tue, 06 Oct 2009 20:54:02 +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 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?

Thanks,

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/