Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751387AbWBPRi1 (ORCPT ); Thu, 16 Feb 2006 12:38:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751390AbWBPRi1 (ORCPT ); Thu, 16 Feb 2006 12:38:27 -0500 Received: from einhorn.in-berlin.de ([192.109.42.8]:31874 "EHLO einhorn.in-berlin.de") by vger.kernel.org with ESMTP id S1751387AbWBPRi0 (ORCPT ); Thu, 16 Feb 2006 12:38:26 -0500 X-Envelope-From: stefanr@s5r6.in-berlin.de Message-ID: <43F4B796.1010701@s5r6.in-berlin.de> Date: Thu, 16 Feb 2006 18:34:14 +0100 From: Stefan Richter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040914 X-Accept-Language: de, en MIME-Version: 1.0 To: Russell King CC: James Bottomley , Greg KH , Andrew Morton , Linus Torvalds , linux-kernel@vger.kernel.org, Jens Axboe , "Brown, Len" , "David S. Miller" , linux-acpi@vger.kernel.org, linux-usb-devel@lists.sourceforge.net, "Yu, Luming" , Ben Castricum , sanjoy@mrao.cam.ac.uk, Helge Hafting , "Carlo E. Prelz" , Gerrit Bruchh?user , Nicolas.Mailhot@LaPoste.net, Jaroslav Kysela , Takashi Iwai , Patrizio Bassi , Bj?rn Nilsson , Andrey Borzenkov , "P. Christeas" , ghrt , jinhong hu , Andrew Vasquez , linux-scsi@vger.kernel.org, Benjamin LaHaise Subject: Re: Linux 2.6.16-rc3 References: <20060212190520.244fcaec.akpm@osdl.org> <20060213203800.GC22441@kroah.com> <1139934883.14115.4.camel@mulgrave.il.steeleye.com> <1140054960.3037.5.camel@mulgrave.il.steeleye.com> <20060216171200.GD29443@flint.arm.linux.org.uk> In-Reply-To: <20060216171200.GD29443@flint.arm.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: (0.59) AWL,BAYES_50 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1288 Lines: 29 Russell King wrote: > On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote: [...] >>OK, this is what I'm proposing as the device model fix. What it does is >>thread context checking APIs throughout the device subsystem. SCSI can >>then use it simply via device_put_process_context(). [...] >>Since this is planned for post 2.6.16, we have plenty of time to argue >>about it. > > This is probably an idiotic question, but if there's something in the > scsi release handler can't be called in non-process context, why can't > scsi queue up the release processing via the work API itself, rather > than having to have this additional code and complexity for everyone? Moreover, why are SCSI release handlers called in non-process context in the first place? IMO the fix should be to make sure that SCSI release handlers are always called from process context --- by the respective layers which manage physical devices, i.e. one or more layers beneath SCSI core. -- Stefan Richter -=====-=-==- --=- =---- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/