All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy_d_dunlap@linux.intel.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH] shutdown processing
Date: Thu, 16 Feb 2006 11:12:08 -0800	[thread overview]
Message-ID: <20060216111208.2367829b.randy_d_dunlap@linux.intel.com> (raw)
In-Reply-To: <43F4CAF4.1070004@s5r6.in-berlin.de>

On Thu, 16 Feb 2006 19:56:52 +0100
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Randy Dunlap wrote:
> > On Thu, 16 Feb 2006 09:58:33 +0100
> > Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> >>Why are you calling these from SCSI? Wouldn't ahci_pci_driver.remove() 
> >>and piix_pci_driver.remove() be a proper place to perform what you are 
> >>doing in ata_device_shutdown?
> > 
> > Mostly to have the scsi_device pointers available.
> 
> Note that roughly as long a scsi_device exists, SCSI high-level drivers 
> expect to be able to send commands to them. In particular, when 
> scsi_remove_device is called, (or scsi_remove_host, which calls 
> scsi_remove_device for all still existing devices of a host), the SCSI 
> high-level drivers' shutdwon methods get executed. Some of them send 
> SCSI commands. The upshot is, a SCSI low-level driver has to be able to 
> handle newly enqueued command while it is calling 
> scsi_remove_{device,host}. Moreover it must not block a SCSI host at 
> this moment.
> 
> IOW the most natural order for layers to shut down would be first SCSI, 
> then ATA. (But then, I don't really comprehend whether your shutdown 
> code would actually collide with that of the SCSI subsystem at all.)

OK, now it seems like you just told me why I shouldn't use
the pci_driver.remove() interface.  But thanks for your comments,
I do appreciate them and will dig deeper [into a twisty maze :].

anyone else care to comment on this?

---
~Randy

  reply	other threads:[~2006-02-16 19:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-15 19:46 [PATCH] shutdown processing Randy Dunlap
2006-02-16  8:58 ` Stefan Richter
2006-02-16 18:40   ` Randy Dunlap
2006-02-16 18:56     ` Stefan Richter
2006-02-16 19:12       ` Randy Dunlap [this message]
2006-02-17 19:15         ` Stefan Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060216111208.2367829b.randy_d_dunlap@linux.intel.com \
    --to=randy_d_dunlap@linux.intel.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.