From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: ata_ram driver Date: Fri, 07 Mar 2008 09:43:22 +0900 Message-ID: <47D08FAA.7070001@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from wa-out-1112.google.com ([209.85.146.177]:28697 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759538AbYCGAnc (ORCPT ); Thu, 6 Mar 2008 19:43:32 -0500 Received: by wa-out-1112.google.com with SMTP id v27so192028wah.23 for ; Thu, 06 Mar 2008 16:43:30 -0800 (PST) In-Reply-To: <1204850398.3062.111.camel@localhost.localdomain> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: James Bottomley Cc: Mark Lord , Matthew Wilcox , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, Jeff Garzik 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