| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <48E4FE3F.2080707@vlnb.net>
Date: Thu, 02 Oct 2008 21:00:47 +0400
From: Vladislav Bolkhovitin <vst@...b.net>
To: "Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC: linux-iscsi-target-dev@...glegroups.com,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
Mike Christie <michaelc@...wisc.edu>,
linux-scsi <linux-scsi@...r.kernel.org>,
iet-dev <iscsitarget-devel@...ts.sourceforge.net>,
Greg KH <greg@...ah.com>,
Jerome Martin <tramjoe.merin@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
James Bottomley <James.Bottomley@...senPartnership.com>,
SCST-Devel <scst-devel@...ts.sourceforge.net>,
Joel Becker <joel.becker@...cle.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target
Stack on v2.6.27-rc7
Nicholas A. Bellinger wrote:
>>> # Add some more HBA and storage Objects
>>> 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
>> It'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 ;)
>>
>
> 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.
There's one unsolved problem. As I've already written, SCST core needs
an ability to provide to user space a large amount of data, which may
not fit to a single page. A list of connected initiators ("sessions"
file in /proc), for instance. Each initiator in that list has a number
of attributes: initiator name, target template name, count of
outstanding commands, etc. The logical way for that would be to create a
subdirectory for each initiator, like:
/sys/kernel/config/
`-- target
`-- sessions
`-- session1
| |-- initiator_name
| |-- template_name
| `-- commands
|
`-- session2
|-- initiator_name
`-- template_name
`-- commands
But looks like configfs requires each subdirectory to be created
manually by user via, e.g., mkdir command. It would be really strange if
we require user to manually create "sessions" subdirectory to be able to
see a list of connected initiators. Do I miss anything?
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists