All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: dgilbert@interlog.com,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: scsi_alloc_target: parent of the target (need not be a scsi host)
Date: Sun, 10 May 2020 11:52:39 -0700	[thread overview]
Message-ID: <1589136759.9701.25.camel@HansenPartnership.com> (raw)
In-Reply-To: <59d462c4-ceab-041a-bbb5-5b509f13a123@interlog.com>

On Sun, 2020-05-10 at 14:32 -0400, Douglas Gilbert wrote:
> This gem is in scsi_scan.c in the documentation of that function's
> first argument. "need not be a scsi host" should read "it damn well
> better be a scsi host" otherwise that function will crash and burn!

It shouldn't: several transport classes, like SAS and FC have
intermediate devices between the host and the target and they all work
just fine using the non-host parent.  Since you don't give the error
this is just guesswork, but the host has to be somewhere in the parent
chain otherwise dev_to_shost(parent) will return NULL ... is that your
problem?

> I'm trying to work out why the function: starget_for_each_device() in
> scsi.c does _not_ use that collection right in front of it (i.e.
> scsi_target::devices). Instead, it step up to the host level, and
> iterates over all devices (LUs) on that host and only calls the given
> function for those devices that match the channel and target numbers.
> That is bizarrely wasteful if scsi_target::devices could be iterated
> over instead.
> 
> Anyone know why this is?

Best guess would be it wasn't converted over when the target list was
introduced.

James


  reply	other threads:[~2020-05-10 18:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 18:32 scsi_alloc_target: parent of the target (need not be a scsi host) Douglas Gilbert
2020-05-10 18:52 ` James Bottomley [this message]
2020-05-10 21:50   ` Douglas Gilbert
2020-05-11 14:41     ` James Bottomley
2020-05-11 18:31       ` Douglas Gilbert

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=1589136759.9701.25.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dgilbert@interlog.com \
    --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 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.