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.
Bart.
--
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
