[PATCH] LIBISCSI: Added new boot entries in the session sysfs
This is the kernel part of the modification to extract the net params
from the ibft sysfs to the iface struct used for the connection
request upon sync_session in the open-iscsi util.
Three new session sysfs params are defined:
boot_root - holds the name of the /sys/firmware/ibft or iscsi_rootN
boot_nic - holds the ethernetN name
boot_target - holds the targetN name
Signed-off-by: Eddie Wai eddie@broadcom.com
---
drivers/scsi/libiscsi.c | 18 ++
drivers/scsi/scsi_transport_iscsi.c | 12
include/scsi/iscsi_if.h |4
include/scsi/libiscsi.h |4
4 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 5de9469..ae69dfc 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2808,6 +2808,9 @@ void iscsi_session_teardown(struct iscsi_cls_session
*cls_session)
kfree(session-targetname);
kfree(session-targetalias);
kfree(session-initiatorname);
+ kfree(session-boot_root);
+ kfree(session-boot_nic);
+ kfree(session-boot_target);
kfree(session-ifacename);
iscsi_destroy_session(cls_session);
@@ -3248,6 +3251,12 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
return iscsi_switch_str_param(session-ifacename, buf);
case ISCSI_PARAM_INITIATOR_NAME:
return iscsi_switch_str_param(session-initiatorname, buf);
+ case ISCSI_PARAM_BOOT_ROOT:
+ return iscsi_switch_str_param(session-boot_root, buf);
+ case ISCSI_PARAM_BOOT_NIC:
+ return iscsi_switch_str_param(session-boot_nic, buf);
+ case ISCSI_PARAM_BOOT_TARGET:
+ return iscsi_switch_str_param(session-boot_target, buf);
default:
return -ENOSYS;
}
@@ -3326,6 +3335,15 @@ int iscsi_session_get_param(struct iscsi_cls_session
*cls_session,
case ISCSI_PARAM_INITIATOR_NAME:
len = sprintf(buf, %s\n, session-initiatorname);
break;
+ case ISCSI_PARAM_BOOT_ROOT:
+ len = sprintf(buf, %s\n, session-boot_root);
+ break;
+ case ISCSI_PARAM_BOOT_NIC:
+ len = sprintf(buf, %s\n, session-boot_nic);
+ break;
+ case ISCSI_PARAM_BOOT_TARGET:
+ len = sprintf(buf, %s\n, session-boot_target);
+ break;
default:
return -ENOSYS;
}
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 133926b..abf7c40 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -3473,6 +3473,9 @@ iscsi_session_attr(tgt_reset_tmo,
ISCSI_PARAM_TGT_RESET_TMO, 0);
iscsi_session_attr(ifacename, ISCSI_PARAM_IFACE_NAME, 0);
iscsi_session_attr(initiatorname, ISCSI_PARAM_INITIATOR_NAME, 0);
iscsi_session_attr(targetalias, ISCSI_PARAM_TARGET_ALIAS, 0);
+iscsi_session_attr(boot_root, ISCSI_PARAM_BOOT_ROOT, 0);
+iscsi_session_attr(boot_nic, ISCSI_PARAM_BOOT_NIC, 0);
+iscsi_session_attr(boot_target, ISCSI_PARAM_BOOT_TARGET, 0);
static ssize_t
show_priv_session_state(struct device *dev, struct device_attribute *attr,
@@ -3568,6 +3571,9 @@ static struct attribute *iscsi_session_attrs[] = {
dev_attr_sess_ifacename.attr,
dev_attr_sess_initiatorname.attr,
dev_attr_sess_targetalias.attr,
+ dev_attr_sess_boot_root.attr,
+ dev_attr_sess_boot_nic.attr,
+ dev_attr_sess_boot_target.attr,
dev_attr_priv_sess_recovery_tmo.attr,
dev_attr_priv_sess_state.attr,
dev_attr_priv_sess_creator.attr,
@@ -3631,6 +3637,12 @@ static umode_t iscsi_session_attr_is_visible(struct
kobject *kobj,
param = ISCSI_PARAM_INITIATOR_NAME;
else if (attr == dev_attr_sess_targetalias.attr)
param = ISCSI_PARAM_TARGET_ALIAS;
+ else if (attr == dev_attr_sess_boot_root.attr)
+ param = ISCSI_PARAM_BOOT_ROOT;
+ else if (attr == dev_attr_sess_boot_nic.attr)
+ param = ISCSI_PARAM_BOOT_NIC;
+ else if (attr == dev_attr_sess_boot_target.attr)
+ param = ISCSI_PARAM_BOOT_TARGET;
else if (attr == dev_attr_priv_sess_recovery_tmo.attr)
return S_IRUGO | S_IWUSR;
else if (attr == dev_attr_priv_sess_state.attr)
diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
index fe7f06c..f9cc89b 100644
--- a/include/scsi/iscsi_if.h
+++ b/include/scsi/iscsi_if.h
@@ -487,6 +487,10 @@ enum iscsi_param {
ISCSI_PARAM_TGT_RESET_TMO,
ISCSI_PARAM_TARGET_ALIAS,
+ ISCSI_PARAM_BOOT_ROOT,
+ ISCSI_PARAM_BOOT_NIC,
+ ISCSI_PARAM_BOOT_TARGET,
+
ISCSI_PARAM_CHAP_IN_IDX,
ISCSI_PARAM_CHAP_OUT_IDX,
/* must always be last */
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 09c041e..4265a4b 100644
---
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
-Original Message- From: Eddie Wai w...@broadcom.com Date: Wednesday 5 June 2013 7:00 AM To: shyam_i...@dell.com shyam_i...@dell.com Cc: open-iscsi@googlegroups.com open-iscsi@googlegroups.com, Vikas vikas.chaudh...@qlogic.com, Lalit Chandivade lalit.chandiv...@qlogic.com, Ravi Anand ravi.an...@qlogic.com, Poornima Vonti poornima.vo...@qlogic.com, Manish Rangankar manish.rangan...@qlogic.com, Adheer Chandravanshi adheer.chandravan...@qlogic.com Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs entries correctly. Although we have not proposed this via the netdev ML yet, however, the current suggestion to only add ethtool extension to support this is gaining traction. As far as latency goes, a simple
