From: Mike Anderson <andmike@us.ibm.com>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] make the SCSI mid-layer obey the device online flag
Date: Wed, 4 Jun 2003 09:51:46 -0700 [thread overview]
Message-ID: <20030604165146.GA1426@beaverton.ibm.com> (raw)
In-Reply-To: <1054742495.1674.18.camel@mulgrave>
James Bottomley [James.Bottomley@steeleye.com] wrote:
> It has been pointed out by the USB people that the mid-layer doesn't
> obey its own online flag.
>
> The attached patch should fix this. However, there are a few caveats to
> offlining (read that as devices should still be prepared to process
> commands).
>
> 1. Any special command will still be accepted (that's a command either
> via the SCSI_IOCTL_SEND_COMMAND, or an internally generated command).
> 2. Outstanding already processed commands in the queue (i.e. commands
> which have already been through the upper layer drivers but needed
> requeuing for some reason like QUEUE_FULL or device busy).
>
> I'm willing to consider changing 2., it just requires more speciallised
> logic to distinguish between a command that has been prepared by the
> upper level drivers and a command sent via 1.
>
> However, not that LLDs may not assume they will receive no commands just
> because scsi_device->online is zero.
>
> James
>
Doesn't this patch just re-implement in the prep_fn what is already
being done by sd and sr in there init_command functions.
Why allow io after online goes to zero. The user could bring the device
back online if they needed to send IO. I was counting on no IO so we could
do faster cleanup in the scsi_remove_host function.
I having been looking at this, but it is not very clean. To use existing
common functionality and avoid deadlock from calling back into the
request_fn the command needs wasted preparation just to use common
interfaces.
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2003-06-04 16:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 16:01 [PATCH] make the SCSI mid-layer obey the device online flag James Bottomley
2003-06-04 16:51 ` Mike Anderson [this message]
2003-06-04 19:14 ` James Bottomley
2003-06-05 0:34 ` Patrick Mansfield
2003-06-05 12:59 ` James Bottomley
2003-06-05 13:41 ` Alan Stern
2003-06-06 6:36 ` Christoph Hellwig
2003-06-06 15:19 ` James Bottomley
2003-06-06 15:51 ` Oliver Neukum
2003-06-06 16:02 ` Luben Tuikov
2003-06-06 15:28 ` Luben Tuikov
2003-06-06 15:39 ` James Bottomley
2003-06-06 15:52 ` Luben Tuikov
2003-06-06 16:04 ` James Bottomley
2003-06-06 20:51 ` Christoph Hellwig
2003-06-06 23:27 ` Luben Tuikov
2003-06-06 23:43 ` James Bottomley
2003-06-07 5:20 ` Luben Tuikov
2003-06-06 20:23 ` Mike Anderson
2003-06-06 20:52 ` Christoph Hellwig
2003-06-10 0:00 ` Mike Anderson
2003-06-06 20:49 ` Christoph Hellwig
2003-06-06 23:21 ` Luben Tuikov
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=20030604165146.GA1426@beaverton.ibm.com \
--to=andmike@us.ibm.com \
--cc=James.Bottomley@steeleye.com \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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.