On Tue, Mar 15, 2011 at 11:08 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote: > On 03/15/2011 01:55 PM, Christoph Hellwig wrote: >> >> On Tue, Mar 15, 2011 at 01:47:12PM -0400, Jeff Garzik wrote: >>> >>> Let's get this driver into staging for 2.6.39, if it isn't going to >>> hit the merge window for 2.6.39. >>> >>> It would lame for such [presumably] high volume hardware to be in >>> neither the main kernel, nor staging, at 2.6.39 release time. >> >> What's the point of staging? That just causes tons of poinless churn. >> Linus has made it clear that normal high volume hardware drivers can go >> in after the merge window. So let's just polish it for another few >> weeks and then put it in where it belongs. > > That's fine... if that really happens. > > It seemed like this was turning into another driver that would get held > outside the kernel until it's "perfect." If that is the case, Linus has > also made it clear we should get drivers for high volume, shipping hardware > into the kernel, even if its staging, if the alternative is to deny users > the driver. > Whether it is drivers/staging/ or drivers/scsi/ having a few more weeks to at least allow for a SCSI focused review (and the resulting cleanups / fixes) before merging is the important point. Staging does not seem to be the location for high volume cleanups after the merge window closes: $ git diff --stat -M v2.6.38-rc1..v2.6.38 drivers/staging/ 50 files changed, 832 insertions(+), 476 deletions(-) ...though there is a precedent for taking large staging drivers post merge window (commit 9d200153: Staging: add MSM framebuffer driver). This looks like a way forward. Barring objections I would also go ahead and get the current git tree into -next just to flush out any build / integration issues. If we (community) end up deciding the driver should still go to staging I can just do a late "git mv drivers/scsi/isci drivers/staging/" prior to sending the pull request to Greg. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
