From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Questions about scsi_target_reap and starget/sdev lifecyle
Date: Tue, 14 Jun 2005 22:28:59 -0500 [thread overview]
Message-ID: <1118806139.5027.37.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0506141714530.4698-100000@iolanthe.rowland.org>
On Tue, 2005-06-14 at 17:27 -0400, Alan Stern wrote:
> Can you or anyone else please explain what scsi_target_reap() and
> especially what scsi_target.reap_ref are for? What's the point of this
> home-brewed reference counting scheme when there's already a perfectly
> useful embedded struct device inside scsi_target? Why isn't
> scsi_target_reap() simply the release routine for the embedded device?
Look at how scsi_target_reap works: it's the decider for visibility
removal, not actual release, that's why we can't use the device
reference, which is the decider for release. I could have used a kref,
but, given the special locking conventions and the tying to the __target
list, the call would have had to be wrappered anyway, so there didn't
seem to to be much point.
A target is basically a self destroying entity which is why the
complexity.
> In addition, can someone please explain how long a scsi_target structure
> and a scsi_device structure are supposed to remain linked into the host's
> __targets and __devices lists once they have been removed? The
> scsi_device link isn't severed until the release routine runs, which can
> be quite a long time after the device has been removed. The scsi_target
> link is severed in scsi_target_reap(), which should be thought of as a
> kind of release routine as well.
__target entries are removed when the target goes invisible (and for
this to happen, all the devices have to be already gone). __devices
when the device is released.
> Won't this cause trouble in a hotplug environment? A target or a LUN can
> be removed, and while it's still on the host's list a new target or LUN
> could be discovered with the same ID. Having multiple entries on a list
> with the same ID sounds like a bad idea. Is there some reason why these
> things aren't taken off their list as soon as they are removed?
It shouldn't, that's what rescan is about. If the device isn't gone,
you get the old device back again.
James
next prev parent reply other threads:[~2005-06-15 3:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-14 21:27 Questions about scsi_target_reap and starget/sdev lifecyle Alan Stern
2005-06-15 3:28 ` James Bottomley [this message]
2005-06-15 20:07 ` Alan Stern
2005-06-15 21:11 ` Alan Stern
2005-06-15 23:03 ` James Bottomley
2005-06-16 2:22 ` Alan Stern
2005-06-16 7:31 ` Mike Anderson
2005-06-16 13:57 ` James Bottomley
2005-06-17 2:01 ` Alan Stern
2005-06-18 20:14 ` Alan Stern
2005-06-20 15:52 ` Brian King
2005-06-20 16:35 ` Alan Stern
2005-06-20 17:31 ` Patrick Mansfield
2005-06-20 19:24 ` Alan Stern
2005-06-21 17:12 ` Mike Anderson
2005-06-21 17:43 ` Patrick Mansfield
2005-06-21 19:24 ` Mike Anderson
2005-06-21 20:04 ` Alan Stern
2005-06-21 20:10 ` Christoph Hellwig
2005-06-21 20:33 ` Alan Stern
2005-06-21 20:58 ` Mike Anderson
2005-06-21 21:22 ` Alan Stern
2005-06-22 13:44 ` Luben Tuikov
2005-06-22 13:36 ` Luben Tuikov
2005-06-22 15:12 ` Alan Stern
2005-06-22 15:46 ` Luben Tuikov
2005-06-22 16:16 ` Alan Stern
2005-06-22 16:53 ` Luben Tuikov
2005-06-21 21:08 ` Mike Anderson
2005-06-21 21:37 ` Alan Stern
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=1118806139.5027.37.camel@mulgrave \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox