> No, sorry for have been unclear. I want a pointer to the remote port > structure in the fc_target transport data. Every driver needs the > linkage of these two, and instead of everyone having it in their > private data we'd better move it to the fc_transport data structure.
Ok. It's already there. What this boils down do is exactly your last statement (and our driver doesn't do it - we'll fix it). Note: there's a flipside here... with the remote port stuff, we had removed almost all the reasons for a fc driver to reference a scsi_target. The only place we really had to was in the case the older fc_transport/xxx sysfs attributes (which all but one exist only for compatibility). We could move this into the remote port structure (already set up for this) which will always exist for a scsi_target. Even so, I think extending the scsi target and fixing the calling sequence is the correct thing to do. > What about dropping the > counters temporarily > for submission and submit a patch later that adds them (and > their sysfs > exposure) back at the midlayer? In fact the actual > accounting is better > done at the midlayer-level anyway. OK. -- 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
