public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Aboo Valappil <aboo@aboo.org>
Cc: dougg@torque.net, linux-scsi@vger.kernel.org
Subject: Re: Linux Virtual SCSI HBAs and Virtual disks
Date: Tue, 23 Jan 2007 18:16:56 +0100	[thread overview]
Message-ID: <45B64308.1060703@s5r6.in-berlin.de> (raw)
In-Reply-To: <45B60993.9070508@aboo.org>

Aboo Valappil wrote:
> I implemented a new IOCTL to remove  this  scsi_host  if the user 
> process really needs to.  This removal  will first  finish all the SCSI 
> commands (With the above status results) queued on the scsi_host  (If at 
> all) and then remove the scsi_host.  Also the module unload will delete 
> all the scsi_hosts created after finishing all the commands queued with 
> the above status and sense information.

This is a valid approach, but probably more useful would be something like:
  - userspace device server or "modprobe -r" or procfs/sysfs magic or
    whatever else requests removal of a Scsi_Host (or merely of a single
    scsi_device),
  - vscsihba enters scsi_remove_host() or scsi_remove_device(),
  - SCSI core and upper layers do whatever it takes to withdraw from
    the respective I-T(-L) nexus gracefully (e.g. synchronize cache,
    unlock drive door...),
  - userspace device server handles any previously remaining commands
    and the new shutdown commands like intended,
  - SCSI core and upper layers are finished with their business,
    the respective Scsi_Host or scsi_device does not exist anymore now,
    vscsihba leaves scsi_remove_host() or scsi_remove_device(),
  - vscsihba tells userspace device server somehow that there will be
    no further requests, ever.

That way, your "virtual" device server is exposed to everything which a
"real" device server would be too when a Linux initiator shuts the
connection down. Could be interesting to testbed device servers as well
as to userspace bridges to "real" device servers.

When implemented, the "graceful shutdown" path should look almost
exactly like the opposite of the start-up path. The "hot-unplug" path
looks a little different because vscsihba has to go through that path
without assistance of the userspace server. Ideally, the "hot-unplug"
path would actually be the "graceful shutdown" path plus a few little
extra measures to account for premature absence of the device server.

[Of course, I'm saying all this without ever having designed a Linux
SCSI LLD myself, only from the background of maintaining an LLD written
by other people...]
-- 
Stefan Richter
-=====-=-=== ---= =-===
http://arcgraph.de/sr/

  parent reply	other threads:[~2007-01-23 17:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-16 10:22 Linux Virtual SCSI HBAs and Virtual disks Aboo Valappil
2007-01-16 21:52 ` Erik Mouw
2007-01-16 23:01   ` aboo
2007-01-17  1:50 ` Douglas Gilbert
2007-01-17  8:36   ` Stefan Richter
2007-01-17 10:24     ` Aboo Valappil
2007-01-17 22:20       ` Douglas Gilbert
2007-01-17 21:59         ` aboo
2007-01-18  0:38           ` Stefan Richter
2007-01-21  9:48         ` Aboo Valappil
2007-01-21  9:53           ` Aboo Valappil
2007-01-21 11:24             ` Stefan Richter
2007-01-22  0:43               ` aboo
2007-01-22  2:23                 ` aboo
2007-01-22 16:47                   ` Stefan Richter
2007-01-22 16:58                     ` Stefan Richter
2007-01-22 18:07                     ` James Bottomley
2007-01-23 13:11                     ` Aboo Valappil
2007-01-23 16:36                       ` Randy Dunlap
2007-01-23 17:22                         ` Stefan Richter
2007-01-24  9:47                           ` Aboo Valappil
2007-01-25 22:02                           ` Aboo Valappil
2007-01-23 17:16                       ` Stefan Richter [this message]
2007-01-23 22:12                         ` Aboo Valappil
2007-01-24  0:09                           ` Stefan Richter
2007-01-24  3:24                       ` Douglas Gilbert
2007-01-24  9:40                         ` Aboo Valappil
2007-01-25 21:41                         ` Aboo Valappil
2007-01-25 22:01                           ` 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=45B64308.1060703@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=aboo@aboo.org \
    --cc=dougg@torque.net \
    --cc=linux-scsi@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox