From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761331Ab0J0O2D (ORCPT ); Wed, 27 Oct 2010 10:28:03 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54122 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758961Ab0J0O2B (ORCPT ); Wed, 27 Oct 2010 10:28:01 -0400 Subject: Re: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37 From: James Bottomley To: Andi Kleen Cc: "Nicholas A. Bellinger" , Mike Anderson , linux-kernel , linux-scsi , Vasu Dev , Tim Chen , Matthew Wilcox , Mike Christie , Jens Axboe , James Smart , Andrew Vasquez , FUJITA Tomonori , Hannes Reinecke , Joe Eykholt , Christoph Hellwig , Jon Hawley , Brian King , Christof Schmitt , Tejun Heo , Andrew Morton , "H. Peter Anvin" In-Reply-To: <20101027075349.GA32585@gargoyle.fritz.box> References: <1287607774.10283.78.camel@haakon2.linux-iscsi.org> <20101021150840.GA24309@linux.vnet.ibm.com> <1288130914.5169.97.camel@haakon2.linux-iscsi.org> <1288132071.8283.689.camel@mulgrave.site> <1288132464.5169.112.camel@haakon2.linux-iscsi.org> <1288133450.8283.723.camel@mulgrave.site> <1288134048.5169.132.camel@haakon2.linux-iscsi.org> <1288134713.19649.11.camel@mulgrave.site> <1288135918.5169.149.camel@haakon2.linux-iscsi.org> <20101027075349.GA32585@gargoyle.fritz.box> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Oct 2010 09:27:38 -0500 Message-ID: <1288189658.4692.13.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2010-10-27 at 09:53 +0200, Andi Kleen wrote: > > This sounds like a pretty reasonable compromise that I think is slightly > > less risky for the LLDs with the ghosts and cob-webs hanging off of > > them. > > They won't get tested either next release cycle. Essentially > near nobody uses them. > > > > > What do you think..? > > Standard linux practice is to simply push the locks down. That's a pretty > mechanical operation and shouldn't be too risky > > With some luck you could even do it with coccinelle. Precisely ... if we can do the push down now as a mechanical transformation we can put it in the current merge window as a low risk API change. This gives us optimal exposure to the rc sequence to sort out any problems that arise (or drivers that got missed) with the lowest risk of such problems actually arising. Given the corner cases and the late arrival of fixes, the serial number changes are just too risky for the current merge window. Having an API that changes depending on a flag is also a high risk process because it's prone to further sources of error. James