On Thu, 2015-04-09 at 13:36 +0200, Bart Van Assche wrote: > On 04/08/15 18:20, Christoph Hellwig wrote: > > On Wed, Apr 08, 2015 at 09:58:09AM +0200, Bart Van Assche wrote: > >> - Modify the second argument of the get_pr_transport_id() callback from > >> struct se_node_acl * into the initiator port name. That port name is namely > >> the only information used by the get_pr_transport_id() callback functions. > > > > This sounds like a good start, but I'd actually prefer to go one step > > further: > > > > - add a protocol identifier field to the target template instead of > > the .get_fabric_proto_ident method. > > - provide a default implementation of .tpg_get_pr_transport_id, > > .tpg_get_pr_transport_id_len and .tpg_parse_pr_out_transport_id in > > the core instead of all the duplicate switch tables. > > - have default implementations in the core of ->get_pr_transport_id, > > Hello Christoph, > > This makes sense to me. The only reason why the target core needs the > help of a target driver for processing PR commands is to build the > TransportID for initiator ports (section 7.6.4 in SPC-5). While configfs > uses an ASCII representation for the initiator port identifier, that > identifier is stored in binary form in the TransportID. So a choice will > have to be made when the conversion of initiator port ID should happen. > Should this happen when an ACL is created in configfs which means that > the binary initiator port ID has to be stored in the ACL data structure > or should only the ASCII initiator port ID be stored in the ACL data > structure ? With the latter approach the conversion from ASCII to binary > will have to be performed every time a TransportID is built. Neither. The creation of the TransportID needs to be done while PR is happening, and not at explicit configfs or dynamic se_node_acl creation time. The ISCSI Transport ID depends upon the ISID of the current session, and not just what's in se_node_acl->initiatorname[]. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
