From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754560Ab0J0SQu (ORCPT ); Wed, 27 Oct 2010 14:16:50 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33297 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754404Ab0J0SQs (ORCPT ); Wed, 27 Oct 2010 14:16:48 -0400 Subject: Re: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37 From: James Bottomley To: "Nicholas A. Bellinger" Cc: Andi Kleen , 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: <1288202802.5169.202.camel@haakon2.linux-iscsi.org> 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> <1288189658.4692.13.camel@mulgrave.site> <1288202802.5169.202.camel@haakon2.linux-iscsi.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Oct 2010 13:16:36 -0500 Message-ID: <1288203396.6886.19.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 11:06 -0700, Nicholas A. Bellinger wrote: > On Wed, 2010-10-27 at 09:27 -0500, James Bottomley wrote: > > 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. > > I disagree that touching every single legacy LLD's SHT->queuecommand() > and failure paths in that code is a low rist change. It can be done mechanically. > > 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. > > Yes, > > > Given the corner cases and the > > late arrival of fixes, the serial number changes are just too risky for > > the current merge window. > > I think with andmike's testing and ACKs for the necessary scsi_error.c > changes this would be an acceptable risk. I already said why I didn't like this change. Without the serial number, there's no problem. > > Having an API that changes depending on a > > flag is also a high risk process because it's prone to further sources > > of error. > > > > I think this would be considered high risk if the setting of the flag > explictly was required to obtain the default legacy operation. With > this series that is not the case, as the default SHT->unlocked_qcmd=0 > will allow legacy LLDs to function exactly the manner they expect, while > allowing modern LLDs to run in host_lock-less mode. Having a variable API based on a flag elsewhere is always a bad idea. James