Hey Bryant, Any updates wrt getting your WIP code posted in a public repo..? Are there any code items blocking you from making forward progress..? On Sat, 2016-02-27 at 20:30 -0800, Nicholas A. Bellinger wrote: > On Sun, 2016-02-28 at 03:19 +0000, Bryant G Ly wrote: > > Hi Nick, > > Btw, please avoid top-posting in responses, as it makes the thread more > difficult for others to follow. ;) > > > > > This is the current tree I have with my current level of code: > > > > /sys/kernel/config/ > > ├── target > > │ ├── core > > <SNIP> > > > │ ├── ibmvscsis > > │ │ ├── discovery_auth > > │ │ ├── naa.600140530916541d > > │ │ │ ├── fabric_statistics > > │ │ │ └── tpgt_1 > > │ │ │ ├── acls > > │ │ │ ├── attrib > > │ │ │ │ └── fabric_prot_type > > │ │ │ ├── auth > > │ │ │ ├── lun > > │ │ │ │ └── lun_0 > > │ │ │ │ ├── 89926afce -> ../../../../../../target/core/fileio_1/test > > │ │ │ │ ├── alua_tg_pt_gp > > │ │ │ │ ├── alua_tg_pt_offline > > │ │ │ │ ├── alua_tg_pt_status > > | │ │ │ ├── alua_tg_pt_write_md > > │ │ │ │ └── statistics > > │ │ │ │ ├── scsi_port > > │ │ │ │ │ ├── busy_count > > │ │ │ │ │ ├── dev > > │ │ │ │ │ ├── indx > > │ │ │ │ │ ├── inst > > │ │ │ │ │ └── role > > │ │ │ │ ├── scsi_tgt_port > > │ │ │ │ │ ├── dev > > │ │ │ │ │ ├── hs_in_cmds > > │ │ │ │ │ ├── in_cmds > > │ │ │ │ │ ├── indx > > │ │ │ │ │ ├── inst > > │ │ │ │ │ ├── name > > │ │ │ │ │ ├── port_index > > │ │ │ │ │ ├── read_mbytes > > │ │ │ │ │ └── write_mbytes > > │ │ │ │ └── scsi_transport > > │ │ │ │ ├── device > > │ │ │ │ ├── dev_name > > │ │ │ │ ├── indx > > │ │ │ │ └── inst > > │ │ │ ├── nexus > > │ │ │ ├── np > > │ │ │ └── param > > Ok, so you've got a new ../ibmvscsis/$WWPN/$TPGT/nexus attribute. > > Did you add a ibmvscsis per-endpoint 'nexus' configfs attribute handler > for driving se_session creation, via user-space 'echo 1 > ../nexus'..? > > Note that Tomo-san's original code actually drove session creation -> > se_node_acl lookup -> transport_register_session() directly from the > configfs TFO->fabric_make_tpg -> ibmvscsis_make_tpg() callback here: > > https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/tree/drivers/scsi/ibmvscsi/ibmvscsis.c?h=for-next-vscsi#n318 > > and did not use a seperate 'nexus' attribute for this. > > Doing this via a 'nexus' attribute (which existing user-space supports, > a la tcm_loop, vhost_scsi, and xen-scsiback) does make more sense, but > off-hand I don't recall if there was a specific reason it was not done > this way originally. > > > And the Dmesg to go along: > > > > <SNIP> drop the various non ibmvscsis output: > > > [ 3.963121] IBMVSCSIS fabric module v0.1 on Linux/ppc64leon 4.5.0-rc1 > > [ 3.963124] ibmvscsis: getsysteminfo > > [ 3.963135] ibmvscsis: start register template > > [ 3.963138] Setup generic discovery > > [ 3.963140] Setup generic wwn > > [ 3.963141] Setup generic wwn_fabric_stats > > [ 3.963143] Setup generic tpg > > [ 3.963144] Setup generic tpg_base > > [ 3.963145] Setup generic tpg_port > > [ 3.963147] Setup generic tpg_port_stat > > [ 3.963148] Setup generic tpg_lun > > [ 3.963149] Setup generic tpg_np > > [ 3.963150] Setup generic tpg_np_base > > [ 3.963152] Setup generic tpg_attrib > > [ 3.963153] Setup generic tpg_auth > > [ 3.963154] Setup generic tpg_param > > [ 3.963155] Setup generic tpg_nacl > > [ 3.963156] Setup generic tpg_nacl_base > > [ 3.963157] Setup generic tpg_nacl_attrib > > [ 3.963158] Setup generic tpg_nacl_auth > > [ 3.963160] Setup generic tpg_nacl_param > > [ 3.963161] Setup generic tpg_nacl_stat > > [ 3.963162] Setup generic tpg_mappedlun > > [ 3.963164] Setup generic tpg_mappedlun_stat > > [ 3.963166] ibmvscsis: end register template > > [ 3.963184] ibmvscsis: Probe for UA 0x3000000c > > [ 3.963188] ibmvscsis: Probe: liobn 0x1000000c, riobn 0x1300000c > > [ 3.963599] ibmvscsi 3000000b: partner initialized > > [ 3.963626] ibmvscsis: case viosrp mad crq: 0x80, 0x2, 0x0, 0x0, 0x1e, 0x100, 0x18010100 > > [ 3.963648] ibmvscsis: get_remote_info: 0x94 0x1000000c 0xc110000 0x1300000c 0xd008010000000000 > > [ 3.963654] ibmvscsis: Client connect: z2434ev2 (50331648) > > [ 3.963658] ibmvscsis: send info to remote: 0x94 0x1000000c 0xc110000 0x1300000c 0xd008010000000000 > > [ 3.963670] ibmvscsis: send_iu: 0x18 0x1000000c 0xc000000 0x1300000c 0x18010100 > > [ 3.963675] ibmvscsis: crq pre cooked: 0x2, 0x18, 0xc0000001f90001d8 > > [ 3.963677] ibmvscsis: send crq: 0x3000000c, 0x8002009900000018, 0xd80100f9010000c0 > > [ 3.963684] ibmvscsis: finished handle crq now handle cmd > > [ 3.963701] ibmvscsi 3000000b: host srp version: 16.a, host partition z2434ev2 (3), OS 33554432, max io 512 > > [ 3.963715] ibmvscsi 3000000b: sent SRP login > > [ 3.963731] ibmvscsis: case viosrp mad crq: 0x80, 0x1, 0x0, 0x0, 0x3c, 0x100, 0x18010200 > > [ 3.963745] ibmvscsis: send_iu: 0x34 0x1000000c 0xc010000 0x1300000c 0x18010200 > > [ 3.963752] ibmvscsis: crq pre cooked: 0x1, 0x34, 0xc0000001f90003b0 > > [ 3.963756] ibmvscsis: send crq: 0x3000000c, 0x8001009900000034, 0xb00300f9010000c0 > > [ 3.963766] ibmvscsis: finished handle crq now handle cmd > > [ 3.963782] ibmvscsi 3000000b: SRP_LOGIN succeeded > > [ 7.865152] Target_Core_ConfigFS: REGISTER -> group: d0000000026245f0 name: ibmvscsis > > [ 7.865156] Target_Core_ConfigFS: REGISTER -> Located fabric: ibmvscsis > > [ 7.865158] Target_Core_ConfigFS: REGISTER tfc_wwn_cit -> c0000001ec8d3138 > > [ 7.865161] Target_Core_ConfigFS: REGISTER -> Allocated Fabric: ibmvscsis > > <RESTART> > > > [ 8.374865] TARGET_CORE[0]: Loading Generic Kernel Storage Engine: v5.0 on Linux/ppc64le on 4.5.0-rc1 > > [ 8.375215] TARGET_CORE[0]: Initialized ConfigFS Fabric Infrastructure: v5.0 on Linux/ppc64le on 4.5.0-rc1 > > [ 9.229389] IBMVSCSIS fabric module v0.1 on Linux/ppc64leon 4.5.0-rc1 > > [ 9.229392] ibmvscsis: getsysteminfo > > [ 9.229402] ibmvscsis: start register template > > [ 9.229430] ibmvscsis: end register template > > [ 9.229447] ibmvscsis: Probe for UA 0x3000000c > > [ 9.229450] ibmvscsis: Probe: liobn 0x1000000c, riobn 0x1300000c > > [ 9.229794] ibmvscsis: couldn't register crq--rc 0xfffffff0 > > [ 9.229816] ibmvscsis: Error 0xfffffff0 opening virtual adapter > > [ 9.229831] ibmvscsis: failed crq_queue_create ret: -1 > > [ 9.229903] ibmvscsis: probe of 3000000c failed with error -1 > > [ 9.910876] Target_Core_ConfigFS: REGISTER -> group: d0000000051d45f0 name: ibmvscsis > > [ 9.910878] Target_Core_ConfigFS: REGISTER -> Located fabric: ibmvscsis > > [ 9.910879] Target_Core_ConfigFS: REGISTER tfc_wwn_cit -> c0000001ec6f6938 > > [ 9.910880] Target_Core_ConfigFS: REGISTER -> Allocated Fabric: ibmvscsis > > [ 150.261823] TARGET_CORE[ibmvscsis]: Allocated portal_group for endpoint: naa.600140530916541d, Proto: 4, Portal Tag: 1 > > [34016.730043] Setup generic dev > > [34016.730048] Setup generic dev_attrib > > [34016.730050] Setup generic dev_pr > > [34016.730051] Setup generic dev_wwn > > [34016.730053] Setup generic dev_alua_tg_pt_gps > > [34016.730055] Setup generic dev_stat > > [34016.730057] TCM: Registered subsystem plugin: user struct module: d000000008ab3d00 > > [34016.730236] CORE_HBA[1] - Attached HBA to Generic Target Core > > [34016.754179] CORE_HBA[2] - Attached HBA to Generic Target Core > > [34016.754961] Target_Core_ConfigFS: fileio_1/test set udev_path: /tmp/test1.img > > [34016.755188] fileio: Adding to default ALUA LU Group: core/alua/lu_gps/default_lu_gp > > [34016.755243] Vendor: LIO-ORG > > [34016.755245] Model: FILEIO > > [34016.755246] Revision: 4.0 > > [34016.755249] Type: Direct-Access > > [34016.755571] Target_Core_ConfigFS: Set emulated VPD Unit Serial: 6cf8b125-0f83-4bdb-aa96-34da120942e8 > > [34057.245997] ibmvscsis_TPG[1]_LUN[0] - Activated ibmvscsis Logical Unit from CORE HBA: 2 > > > > > > One big thing I noticed was that adding the ibmvscsis.conf file for > > some reason caused the target to de-register and reregister... which > > then caused another init of the ibmvscsis.module, hence the failure in > > probing on the second one. > > Keep in mind the /var/target/fabric/ibmvscsis.spec from our off-list > email only works for non rtslib-fb based code. > > Can you confirm what user-space your currently using..? > > > > > Also, in regards to having the code on a public git, it's still in the > > works. I have sent a proposal to our legal team, hopefully it will be > > approved soon. > > > > Yes, please. > > > Lastly, would you like everything hosted on your end, or should we (as > > ibm) provide the full kernel on github? I think having something like > > your old repo > > (git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core.git), > > would be best? Let me know what you think. > > A repo on github is useful for groking early WIP code. > > As the code gets up and running, and posted to target-devel for review, > target-pending.git/for-next-merge is location for new fabric drivers > going upstream. > > -- > 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 -- 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
