On Wed, 23 Mar 2011 14:17:10 -0700 "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > On Wed, 2011-03-23 at 21:04 +0900, FUJITA Tomonori wrote: > > On Wed, 23 Mar 2011 03:00:03 -0700 > > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > > > On Wed, 2011-03-23 at 17:48 +0900, FUJITA Tomonori wrote: > > > > On Wed, 23 Mar 2011 01:26:30 -0700 > > > > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > Demo-mode means that a struct se_node_acl will be dynamically allocated > > > > > when core_tpg_check_initiator_node_acl() is called for an unknown SCSI > > > > > Initiator WWN in the process of creating a new I_T nexus (struct > > > > > se_session) when struct target_core_fabric_ops->tpg_check_demo_mode()=1 > > > > > is set. > > > > > > > > Again, acl is not irrelevant for ibmvscsis. So I shoundn't set up > > > > it. > > > > > > > > All I asking for is simply accepting any initiators and exporting all > > > > the luns in a target. > > > > > > > > > > > > > > Yes, I understand this. But driving (from kernel-level) a default set > > > of fabric TPG LUN exports for all available target_core_mod backend > > > export is not a manageable way for /sys/kernel/config/target/$HBA/$DEV > > > backend export. This needs to be driven from python library code for > > > userspace applications automatically without interaction from end user > > > for ibmvscsis or any other fabric module. > > > > Hmm, you still don't understand. > > > > Again, there is no 'TPG' concept in SRP transport. > > > > Yes, I understand that there is no hard requirement for a fabric level > concept of a TPG in SRP. Hard requirement? No, please read SRP spec? There is not such thing. So forcing TPG is the wrong desing. Requirements must be in all the transport specs. Transport specific things such as TPG shouldn't be exported to every transports. Again, the point is that the current design is pretty tied to iSCSI. Other transports are forced to handle iSCSI specific stuff strangely. -- 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
