From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764867AbYCGAnq (ORCPT ); Thu, 6 Mar 2008 19:43:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758115AbYCGAnd (ORCPT ); Thu, 6 Mar 2008 19:43:33 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]:29131 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759438AbYCGAnc (ORCPT ); Thu, 6 Mar 2008 19:43:32 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Pdo5c93cc6mo2cpFxNGCZxiQLRXCiHGYCD6GyiyOeShcXUdedUzJQda6r53LkqYSGhLvdqSaKOoi0Cq7vXjvYiNbcS6m2bem/rn9VcLqTJoTPxI+WCAkzIRyVewF6g307wQ9zQNVesimcoBUVzMn0+BSRxr5JsRDvjOEdUqgY3E= Message-ID: <47D08FAA.7070001@gmail.com> Date: Fri, 07 Mar 2008 09:43:22 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.9 (X11/20070801) MIME-Version: 1.0 To: James Bottomley CC: Mark Lord , Matthew Wilcox , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, Jeff Garzik Subject: Re: ata_ram driver References: <20080222200951.GI16995@parisc-linux.org> <47BF3E54.9050609@rtr.ca> <47CFA9A6.2040506@gmail.com> <1204817301.3062.3.camel@localhost.localdomain> <47D08478.8010700@gmail.com> <1204848119.3062.94.camel@localhost.localdomain> <47D08892.3080209@gmail.com> <1204849353.3062.107.camel@localhost.localdomain> <47D08C32.8060907@gmail.com> <1204850398.3062.111.camel@localhost.localdomain> In-Reply-To: <1204850398.3062.111.camel@localhost.localdomain> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Bottomley wrote: > On Fri, 2008-03-07 at 09:28 +0900, Tejun Heo wrote: >> James Bottomley wrote: >>>> Yeap, sure. It's the combination of things that always made me put this >>>> off. Is there a function I can call to just shutdown the host instead >>>> of destroying it? >>> Not really ... the process of unbinding the ULDs causes their remove >>> methods to call shudown. It is possible to separate this in the ULDS; >>> but the original design was to make remove and shutdown be similar for >>> the very reason that if you're removing the driver with unflushed data >>> in the cache, we'd really like it flushed (flush is called from >>> shutdown) because you have no way to talk to the device after this >>> without reinserting the driver. >> The problem is that libata EH and other stuff aren't ready to let go of >> the SCSI host up until the last moment and that last moment can't be >> moved before SCSI host destruction because shutdown sequence (flush and >> spindown) requires live EH. I think this can be solved by shooting down >> individual sdev's instead of destroying the scsi_host. > > Basically what scsi_scan.c:scsi_forget_host() does? It's used > internally at the moment, but I suppose we could export it. Yeap, exactly. I'll prep a patch after breakfast. -- tejun