> What console messages do you see? Looks like we'd have to add another
> allowed state transition from BLOCKED?
At one point we were seeing
Synchronizing SCSI cache for disk sdc:
FAILED
status = 0, message = 00, host = 1, driver = 00
<5>
messages. However, at this point, the sequencing in the driver for unload,
scsi_host_removal, and datastructure teardown is such that we are avoiding
this condition and removals are clean.
No changes are needed.
> Yes, the allocation would need to be changed a little. But
> hey, I don't
> think we should block merging the driver on this one. We'll probably
> introduce it soon and I'll sign you up for testing that patch on the
> lpfc drivewr when it's ready.
Reasonable.
> > > o what about lpfc_target->rport? This should probably
> better be in
> > > the fc_target structure, no?
> >
> > Anything in lpfc_target would go into the scsi_target hostdata
> > (not fc_target).
>
> I meant fc_target_attrs actually, which is scsi_target transport-data.
>
> The point here is that the rport is a transport-class transport object
> that every driver fully converted to fc_transport needs, so
> it's better
> in transport data as well.
If I understand you - it's the recommendation that the remote port be
part of the fc_target transport data. I disagree. If anything, it would
be the other way around. The port exists before any scsi target (thus it
can't be part of the target allocation). The port can also exist without
being a scsi target, so there's no scsi target structure at all.
>
> Now looking at lpfc_target given that the rport goes away we only
> have the I/O counters left and the nodlist pointer. The I/O counters
> aren't really a driver thing and should probably move to the midlayer
> which only leaves the nodelist as private data in the scsi_device.
>
> Sounds like the way to go?
Nope. The counters are a scsi-thing (not fc-thing), so they make sense
to go into the scsi_target. If you want to make them more general for
all drivers, we can do this. Right now, I wouldn't bother.
-- james s
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
