On Thu, Jan 20, 2005 at 10:54:47AM -0500, [EMAIL PROTECTED] wrote: > > 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.
This sounds like a good idea, but I wonder if we have userland relying on those attributes already. But given that the fc transport class was mostly a joke before you encehanced it it might be worth breaking it.. - 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
