Re: [Patch] Correct issue with midlayer scsi target allocation and transports that create the targets

[Patrick Mansfield <patmans@us.ibm.com>]

On Sat, Jun 11, 2005 at 04:37:45PM +0100, Christoph Hellwig wrote:

> > +	if (shost->transportt->target_parent) {
> > +		spin_lock_irqsave(shost->host_lock, flags);
> > +		parent = shost->transportt->target_parent(shost, channel, id);
> > +		spin_unlock_irqrestore(shost->host_lock, flags);
> > +		if (!parent)
> > +			return NULL;
> > +	}
> 
> Ok, this idea is a lot better, but I think scsi_alloc_target is still
> the wrong place to put this.  It has an explicit parent argument that
> all but one of it's callers get right, and we're now totally ignoring
> and looking it up again when the transport has a ->target_parent method.
> 
> I'm not totally sure where the right place to put it in the
> scsi_scan_host_selected path is, though.  Probably scsi_scan_host_selected
> shoud just become __scsi_scan_host_selected, scsi_scan_host would call
> it directly but the sysfs and legacy procfs scanning would call the method.
> 
> Or it might be better to give the transport completely control over the
> scan sysfs attribute, that way we could even allow scanning by WWNs or
> similar things.

What do you think of Mike C's patch, to add a transportt->scan function?

http://marc.theaimsgroup.com/?l=linux-scsi&m=111671146532103&w=2

It needs a bit more code in the transport compared to the above. It also
allows the transport to more efficiently scan (the transport can scan only
devices it knows are attached, versus all id's up to max_id).

If the scsi_target (sysfs targetC:I:L) was always under the scsi_host
(syfs hostH) in the device tree there would no problem. Then the transport
specific target object (like rport for FC) would have to be parallel to or
under the target.

-- Patrick Mansfield