# Add some more HBA and storage ObjectsIt's good, I like it. The only thing concerns me that, considering how much time *I* spent to understand it, for an average user understanding it can be an unbearable nightmare ;)
target:~# mkdir -p $TARGET/fileio_0/file_object
target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
target:~# mkdir -p $TARGET/pscsi_0/sdd
target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
# Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
# Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
# to lvm_test0 and give it the port symbolic name of lio_east_port
ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
target:~# tree $CONFIGFS
/sys/kernel/config/
`-- target
|-- core
| |-- fileio_0
| | |-- file_object
| | | |-- dev_control
| | | |-- dev_enable
| | | `-- dev_info
| | `-- hba_info
| |-- iblock_0
| | |-- hba_info
| | `-- lvm_test0
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| |-- pscsi_0
| | |-- hba_info
| | `-- sdd
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| |-- rd_dr_0
| | |-- hba_info
| | `-- ramdisk0
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| `-- rd_mcp_0
| |-- hba_info
| `-- ramdisk0
| |-- dev_control
| |-- dev_enable
| `-- dev_info
|-- iscsi
| |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
| | `-- tpgt_1
| | |-- lun
| | | |-- lun_0
| | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
| | | | |-- port_control
| | | | `-- port_info
| | | `-- lun_1
| | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
| | | |-- port_control
| | | `-- port_info
| | |-- np
| | | `-- 172.16.201.137:3260
| | | `-- portal_info
| | |-- tpg_control
| | `-- tpg_enable
| `-- lio_version
`-- version
22 directories, 29 files
Well, the idea is not necessarily making the configfs interface the
easiest to use in the world by user directly through $CONFIGFS, but to
make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
actual UIs for user that interact with generic target core and
$FABRIC_MODs be as simple and elegent as possible.
That is what I believe the balance that a configfs enabled generic
target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
maintainers looking to port their code to use a generic control
infrastructure. :-)
In a few days I'll write a proposed configfs hierarchy for existing SCST /proc interface.
Sounds good! Please let me know if you have questions.