On Fri, Jun 26, 2009 at 12:41:00PM -0400, James Smart wrote: > The LLD should never be calling fc_remote_port_add() twice without an > intervening fc_remote_port_delete(). Which is another way of saying - > yes, it's what you say relative to the rport state values. > > The idea is - the LLD is tracking an external port structure, using > <portid, <wwnn,wwpn>> to track identity, and is keeping a "present" and > "not-present" case. If a new port is deemed "present", it calls > fc_remote_port_add() and when connectivity is lost (aka goes to "not > present") to that port, it calls fc_remote_port_delete(). It should be > very straight forward. > > The rport structure itself, to aid the midlayer, to hide temporary > connectivity losses due to link bounces, controller resets, etc - may > stay around after the delete call, and midlayer calls may enter the > driver for it, but the transport via helper functions, should pick them > off and reject them. Eventually, when the rport exceeds its max > connectivity loss hide value (devloss_tmo), the devloss_tmo_callbk() is > made to tell the driver the rport is truly gone (if it cares), and all > the midlayer structures and scsi objects below the rport are terminated. > After this point, for target id bindings, we keep the rport structure > around - but only as a generic container to hold the binding values. For > all intents and purposes, there's no relationship to the old rport or the > old rport pointer value any more. And if a port eventually comes back > that matches the bindings, we flip the binding container back into a real > rport structure as if we had just allocated it. > > -- james s Thanks for clarifying this. So a LLD has to always follow the add-delete sequence. BTW: I think it could be useful to have this information about the interface between LLD and FC transport in Documentation/scsi/scsi_fc_transport.txt -- Christof Schmitt -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
