From: Robert Love <hidden> Date: 2012-09-10 22:59:08
The following series implements a move from using module parameters
as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure
was added to the kernel a few cycles ago, this series builds on that work.
It moves the create, vn2vn_create, destroy, enable and disable interfaces
from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/.
These interfaces simply are not module configurations- they are control
interfaces.
A second goal of this series is to change the initialization sequence for
a FCoE device. The result of this series is that interfaces created using
libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following
starting steps-
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
2) Configure the port
- Change mode, set ddp_min, etc...
3) Start the port
- Begins discovery and/or login (depending on mode)
4) Destroy the port
- Logout and free all memory
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me that
it might not be a good example. I belive bonding uses two values per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Series compiled and tested against v3.5. libfcoe.ko compile warning fixed
upstream after v3.5, anyone who compiles this can ignore section mismatch
warning. Also note that a modified fcoemon is needed to use the fcoe system
service against this kernel modification. I'd be happy to provide that
fcoemon code on request.
---
Robert Love (5):
libfcoe, fcoe: Allow user to set a ctlr's mode
libfcoe: Create new libfcoe control interfaces
fcoe: Use new fcoe_sysfs control interface
bnx2fc: Use new fcoe_sysfs control interface
libfcoe, fcoe: Remove libfcoe module parameters
Documentation/ABI/testing/sysfs-bus-fcoe | 51 +++++++
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 98 ++++++++-----
drivers/scsi/fcoe/fcoe.c | 229 +++++++++++++++---------------
drivers/scsi/fcoe/fcoe.h | 9 +
drivers/scsi/fcoe/fcoe_ctlr.c | 24 +++
drivers/scsi/fcoe/fcoe_sysfs.c | 139 ++++++++++++++++++
drivers/scsi/fcoe/fcoe_transport.c | 174 ++++-------------------
include/scsi/fcoe_sysfs.h | 5 +
include/scsi/libfcoe.h | 20 ++-
9 files changed, 445 insertions(+), 304 deletions(-)
--
Thanks, //Rob
From: Robert Love <hidden> Date: 2012-09-10 22:59:15
This patch makes the 'mode' attribute of a
fcoe_ctlr_device writale. This allows the user
to store the mode with with the ctlr will be in.
Possible modes would be 'Fabric', or 'VN2VN'.
The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
Drivers must implement the set_fcoe_ctlr_mode routine
to support this feature.
libfcoe offers an exported routine to set a fcoe_ctlr's
mode.
Signed-off-by: Robert Love <redacted>
---
Documentation/ABI/testing/sysfs-bus-fcoe | 8 ++++
drivers/scsi/fcoe/fcoe_ctlr.c | 22 +++++++++++
drivers/scsi/fcoe/fcoe_sysfs.c | 61 +++++++++++++++++++++++++++++-
include/scsi/fcoe_sysfs.h | 1
include/scsi/libfcoe.h | 1
5 files changed, 91 insertions(+), 2 deletions(-)
@@ -9,6 +9,14 @@ Attributes: this value will change the dev_loss_tmo for all FCFs discovered by this controller.+ mode: Display or change the FCoE Controller's mode. Possible+ modes are 'Fabric' and 'VN2VN'. If a FCoE Controller+ is started in 'Fabric' mode then FIP FCF discovery is+ initiated and ultimately a fabric login is attempted.+ If a FCoE Controller is started in 'VN2VN' mode then+ FIP VN2VN discovery and login is performed. A FCoE+ Controller only supports one mode at a time.+ lesb_link_fail: Link Error Status Block (LESB) link failure count. lesb_vlink_fail: Link Error Status Block (LESB) virtual link
@@ -2884,3 +2884,25 @@ void fcoe_ctlr_get_fip_mode(struct fcoe_ctlr_device *ctlr_dev)mutex_unlock(&ctlr->ctlr_mutex);}EXPORT_SYMBOL(fcoe_ctlr_get_fip_mode);++voidfcoe_ctlr_set_fip_mode(structfcoe_ctlr_device*ctlr_dev)+{+structfcoe_ctlr*ctlr=fcoe_ctlr_device_priv(ctlr_dev);++mutex_lock(&ctlr->ctlr_mutex);+switch(ctlr_dev->mode){+caseFIP_CONN_TYPE_VN2VN:+ctlr->mode=FIP_MODE_VN2VN;+break;+caseFIP_CONN_TYPE_FABRIC:+default:+ctlr->mode=FIP_MODE_FABRIC;+break;+}++/* TODO: Probably need to restart the state machine */++mutex_unlock(&ctlr->ctlr_mutex);++}+EXPORT_SYMBOL(fcoe_ctlr_set_fip_mode);
@@ -40,6 +41,46 @@ MODULE_PARM_DESC(fcf_dev_loss_tmo," insulate the loss of a fcf. Once this value is"" exceeded, the fcf is removed.");+#define FCOE_MAX_MODENAME_LEN 20+structfcoe_ctlr_mode_table{+char*modename;+enumfip_conn_typemode;+};++conststructfcoe_ctlr_mode_tablectlr_mode_tbl[]={+{"fabric",FIP_CONN_TYPE_FABRIC},+{"vn2vn",FIP_CONN_TYPE_VN2VN},+{NULL,-1},+};++staticenumfip_conn_typefcoe_parse_mode(constchar*buf,+conststructfcoe_ctlr_mode_table*tbl)+{+intmodeint=-1,i,rv;+char*p,modestr[FCOE_MAX_MODENAME_LEN+1]={0,};++for(p=(char*)buf;*p;p++)+if(!(isdigit(*p)||isspace(*p)))+break;++if(*p)+rv=sscanf(buf,"%20s",modestr);+else+rv=sscanf(buf,"%d",&modeint);++if(!rv)+returnFIP_CONN_TYPE_UNKNOWN;++for(i=0;tbl[i].modename;i++){+if(modeint==tbl[i].mode)+returntbl[i].mode;+if(strcmp(modestr,tbl[i].modename)==0)+returntbl[i].mode;+}++returnFIP_CONN_TYPE_UNKNOWN;+}+/**Theseareusedbythefcoe_*_show_functionroutines,they*areintentionallyplacedinthe.cfileasthey'renotintended
From: Robert Love <hidden> Date: 2012-09-10 22:59:21
This patch is the first in a series that will remove
libfcoe's create, destroy, enable and disable module
parameters and replace them with interface files in
the new /sys/bus/fcoe subsystem.
Old layout:
/sys/module/libfcoe/parameters/{create,destroy,enable,disable,vn2vn_create}
New layout:
/sys/bus/fcoe/ctlr_{create,destroy}
/sys/bus/fcoe/ctlr_X/{enable,disable,start}
This patch moves fcoe drivers to the following
initialization sequence-
1) create/alloc
2) configure
3) start
A control sysfs interface at /sys/bus/fcoe/ctlr_create
is added. Writing the interface name to this file
will allocate memory and create a sysfs entry for a
new fcoe_ctlr_device. The user may then tune the interface in
any desired way. After configuration the user will
echo any value into the /sys/bus/fcoe/devices/ctlr_X/start
interface to proceed with logging in.
VN2VN logins will still use the module parameters.
A follow up patch to this one will make the 'mode'
attribute of the fcoe_ctlr_device writable. Which will
allow a user to change the ctlr's mode to 'VN2VN'.
Signed-off-by: Robert Love <redacted>
---
Documentation/ABI/testing/sysfs-bus-fcoe | 43 ++++++++++++
drivers/scsi/fcoe/fcoe.h | 9 +++
drivers/scsi/fcoe/fcoe_ctlr.c | 2 -
drivers/scsi/fcoe/fcoe_sysfs.c | 78 ++++++++++++++++++++++
drivers/scsi/fcoe/fcoe_transport.c | 105 +++++++++++++++++++++++++++++-
include/scsi/fcoe_sysfs.h | 4 +
include/scsi/libfcoe.h | 14 ++++
7 files changed, 250 insertions(+), 5 deletions(-)
@@ -1,8 +1,37 @@+What: /sys/bus/fcoe/+Date: August 2012+KernelVersion: TBD+Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org+Description: The FCoE bus. Attributes in this directory are control interfaces.+Attributes:++ ctlr_create: 'FCoE Controller' instance creation interface. Writing an+ <ifname> to this file will allocate and populate sysfs with a+ fcoe_ctlr_device (ctlr_X). The user can then configure any+ per-port settings and finally write to the fcoe_ctlr_device's+ 'start' attribute to begin the kernel's discovery and login+ process.++ ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a+ fcoe_ctlr_device's sysfs name to this file will log the+ fcoe_ctlr_device out of the fabric or otherwise connected+ FCoE devices. It will also free all kernel memory allocated+ for this fcoe_ctlr_device and any structures associated+ with it, this includes the scsi_host.+ What: /sys/bus/fcoe/ctlr_X Date: March 2012 KernelVersion: TBD Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org-Description: 'FCoE Controller' instances on the fcoe bus+Description: 'FCoE Controller' instances on the fcoe bus.++ The FCoE Controller now has a three stage creation process.+ 1) Write interface name to ctlr_create 2) Configure the FCoE+ Controller (ctlr_X) 3) Write anything to the FCoE+ Controller's 'start' file to begin discovery and login. The+ FCoE Controller is destroyed by writing it's name, i.e. ctlr_X+ to the ctlr_delete file.+ Attributes: fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
@@ -17,6 +46,18 @@ Attributes: FIP VN2VN discovery and login is performed. A FCoE Controller only supports one mode at a time.+ start: Start the FCoE controller.++ disable: Allow FCoE controller's that support disabling+ to be disabled when any value is written to this+ file. This attribute is only displayed if the+ driver supports it.++ enable: Allow FCoE controller's that support enabling+ to be enabled when any value is written to this+ file. This attribute is only displayed if the+ driver supports it.+ lesb_link_fail: Link Error Status Block (LESB) link failure count. lesb_vlink_fail: Link Error Status Block (LESB) virtual link
@@ -41,6 +42,9 @@ MODULE_PARM_DESC(fcf_dev_loss_tmo," insulate the loss of a fcf. Once this value is"" exceeded, the fcf is removed.");+BUS_ATTR(ctlr_create,S_IWUSR,NULL,fcoe_ctlr_create_store);+BUS_ATTR(ctlr_destroy,S_IWUSR,NULL,fcoe_ctlr_destroy_store);+#define FCOE_MAX_MODENAME_LEN 20structfcoe_ctlr_mode_table{char*modename;
@@ -515,9 +515,8 @@ static int __exit fcoe_transport_exit(void)return0;}-staticintfcoe_add_netdev_mapping(structnet_device*netdev,-structfcoe_transport*ft)+structfcoe_transport*ft){structfcoe_netdev_mapping*nm;
@@ -627,6 +626,108 @@ static int libfcoe_device_notification(struct notifier_block *notifier,returnNOTIFY_OK;}+ssize_tfcoe_ctlr_create_store(structbus_type*bus,+constchar*buf,size_tcount)+{+structnet_device*netdev=NULL;+structfcoe_transport*ft=NULL;+structfcoe_ctlr_device*ctlr_dev=NULL;+intrc=-ENODEV;+interr;++mutex_lock(&ft_mutex);++netdev=fcoe_if_to_netdev(buf);+if(!netdev){+LIBFCOE_TRANSPORT_DBG("Invalid device %s.\n",buf);+rc=-ENODEV;+gotoout_nodev;+}++ft=fcoe_netdev_map_lookup(netdev);+if(ft){+LIBFCOE_TRANSPORT_DBG("transport %s already has existing "+"FCoE instance on %s.\n",+ft->name,netdev->name);+rc=-EEXIST;+gotoout_putdev;+}++ft=fcoe_transport_lookup(netdev);+if(!ft){+LIBFCOE_TRANSPORT_DBG("no FCoE transport found for %s.\n",+netdev->name);+rc=-ENODEV;+gotoout_putdev;+}++/* pass to transport create */+err=ft->alloc?ft->alloc(netdev):-ENODEV;+if(err){+fcoe_del_netdev_mapping(netdev);+rc=-ENOMEM;+gotoout_putdev;+}++err=fcoe_add_netdev_mapping(netdev,ft);+if(err){+LIBFCOE_TRANSPORT_DBG("failed to add new netdev mapping "+"for FCoE transport %s for %s.\n",+ft->name,netdev->name);+rc=-ENODEV;+gotoout_putdev;+}++LIBFCOE_TRANSPORT_DBG("transport %s %s to create fcoe on %s.\n",+ft->name,(ctlr_dev)?"succeeded":"failed",+netdev->name);++out_putdev:+dev_put(netdev);+out_nodev:+mutex_unlock(&ft_mutex);+returnrc;+}++ssize_tfcoe_ctlr_destroy_store(structbus_type*bus,+constchar*buf,size_tcount)+{+intrc=-ENODEV;+structnet_device*netdev=NULL;+structfcoe_transport*ft=NULL;++mutex_lock(&ft_mutex);++netdev=fcoe_if_to_netdev(buf);+if(!netdev){+LIBFCOE_TRANSPORT_DBG("invalid device %s.\n",buf);+gotoout_nodev;+}++ft=fcoe_netdev_map_lookup(netdev);+if(!ft){+LIBFCOE_TRANSPORT_DBG("no FCoE transport found for %s.\n",+netdev->name);+gotoout_putdev;+}++/* pass to transport destroy */+rc=ft->destroy(netdev);+if(rc)+gotoout_putdev;++fcoe_del_netdev_mapping(netdev);+LIBFCOE_TRANSPORT_DBG("transport %s %s to destroy fcoe on %s.\n",+ft->name,(rc)?"failed":"succeeded",+netdev->name);+rc=count;/* required for successful return */+out_putdev:+dev_put(netdev);+out_nodev:+mutex_unlock(&ft_mutex);+returnrc;+}+EXPORT_SYMBOL(fcoe_ctlr_destroy_store);/***fcoe_transport_create()-Createafcoeinterface
@@ -64,6 +67,7 @@ struct fcoe_ctlr_device {intfcf_dev_loss_tmo;enumfip_conn_typemode;+u8started:1;/* expected in host order for displaying */structfcoe_fc_els_lesblesb;
From: Robert Love <hidden> Date: 2012-09-10 22:59:31
Convert bnx2fc to use the new fcoe_sysfs create, delete,
enable, disable, start and mode.
bnx2fc doesn't support VN2VN. bnx2fc will not initialize
the set_fcoe_ctlr_mode routine and therefore its instances
will always be in FABRIC mode. There was previously an
explicit check for the ctlr's mode, but this is no longer
needed because not implementing set_fcoe_ctlr_mode implies
that the ctlr cannot change from the FABRIC mode.
Signed-off-by: Robert Love <redacted>
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 98 +++++++++++++++++++++++--------------
1 file changed, 60 insertions(+), 38 deletions(-)
@@ -2106,20 +2106,6 @@ static int bnx2fc_create(struct net_device *netdev, enum fip_state fip_mode)/* Add interface to if_list */list_add_tail(&interface->list,&if_list);-lport->boot_time=jiffies;--/* Make this master N_port */-ctlr->lp=lport;--if(!bnx2fc_link_ok(lport)){-fcoe_ctlr_link_up(ctlr);-fc_host_port_type(lport->host)=FC_PORTTYPE_NPORT;-set_bit(ADAPTER_STATE_READY,&interface->hba->adapter_state);-}--BNX2FC_HBA_DBG(lport,"create: START DISC\n");-bnx2fc_start_disc(interface);-interface->enabled=true;/**Releasefromkref_initinbnx2fc_interface_setup,onsuccess*lportshouldbeholdingareferencetakeninbnx2fc_if_create
@@ -2128,6 +2114,7 @@ static int bnx2fc_create(struct net_device *netdev, enum fip_state fip_mode)/* put netdev that was held while calling dev_get_by_name */mutex_unlock(&bnx2fc_dev_lock);rtnl_unlock();+return0;if_create_err:
@@ -2145,6 +2132,40 @@ mod_err:}/**+*bnx2fc_alloc-Alocateabnx2fcFCoEinterface+*+*@cdev:TheFCoEControllerDevicetostart+*+*Calledfromsysfs.+*+*Returns:0forsuccess+*/+staticintbnx2fc_start(structfcoe_ctlr_device*cdev)+{+structfcoe_ctlr*ctlr=fcoe_ctlr_device_priv(cdev);+structfc_lport*lport=ctlr->lp;+structfcoe_port*port=lport_priv(lport);+structbnx2fc_interface*interface=port->priv;++lport->boot_time=jiffies;++/* Make this master N_port */+ctlr->lp=lport;++if(!bnx2fc_link_ok(lport)){+fcoe_ctlr_link_up(ctlr);+fc_host_port_type(lport->host)=FC_PORTTYPE_NPORT;+set_bit(ADAPTER_STATE_READY,&interface->hba->adapter_state);+}++BNX2FC_HBA_DBG(lport,"create: START DISC\n");+bnx2fc_start_disc(interface);+interface->enabled=true;++return0;+}++/***bnx2fc_find_hba_for_cnic-mapscnicinstancetobnx2fchbainstance**@cnic:Pointertocnicdeviceinstance
From: Robert Love <hidden> Date: 2012-09-10 22:59:35
This patch removes the create, create_vn2vn, destroy,
enable and disable module parameters. Previous patches
have added these interfaces to the fcoe_sysfs layout
and these misplaced interfaces are no longer necessary.
Signed-off-by: Robert Love <redacted>
---
drivers/scsi/fcoe/fcoe_transport.c | 211 ------------------------------------
include/scsi/libfcoe.h | 7 -
2 files changed, 1 insertion(+), 217 deletions(-)
@@ -32,15 +32,11 @@ MODULE_AUTHOR("Open-FCoE.org");MODULE_DESCRIPTION("FIP discovery protocol and FCoE transport for FCoE HBAs");MODULE_LICENSE("GPL v2");-staticintfcoe_transport_create(constchar*,structkernel_param*);-staticintfcoe_transport_destroy(constchar*,structkernel_param*);staticintfcoe_transport_show(char*buffer,conststructkernel_param*kp);staticstructfcoe_transport*fcoe_transport_lookup(structnet_device*device);staticstructfcoe_transport*fcoe_netdev_map_lookup(structnet_device*device);-staticintfcoe_transport_enable(constchar*,structkernel_param*);-staticintfcoe_transport_disable(constchar*,structkernel_param*);staticintlibfcoe_device_notification(structnotifier_block*notifier,-ulongevent,void*ptr);+ulongevent,void*ptr);staticLIST_HEAD(fcoe_transports);staticDEFINE_MUTEX(ft_mutex);
@@ -55,29 +51,6 @@ module_param_call(show, NULL, fcoe_transport_show, NULL, S_IRUSR);__MODULE_PARM_TYPE(show,"string");MODULE_PARM_DESC(show," Show attached FCoE transports");-module_param_call(create,fcoe_transport_create,NULL,-(void*)FIP_MODE_FABRIC,S_IWUSR);-__MODULE_PARM_TYPE(create,"string");-MODULE_PARM_DESC(create," Creates fcoe instance on a ethernet interface");--module_param_call(create_vn2vn,fcoe_transport_create,NULL,-(void*)FIP_MODE_VN2VN,S_IWUSR);-__MODULE_PARM_TYPE(create_vn2vn,"string");-MODULE_PARM_DESC(create_vn2vn," Creates a VN_node to VN_node FCoE instance "-"on an Ethernet interface");--module_param_call(destroy,fcoe_transport_destroy,NULL,NULL,S_IWUSR);-__MODULE_PARM_TYPE(destroy,"string");-MODULE_PARM_DESC(destroy," Destroys fcoe instance on a ethernet interface");--module_param_call(enable,fcoe_transport_enable,NULL,NULL,S_IWUSR);-__MODULE_PARM_TYPE(enable,"string");-MODULE_PARM_DESC(enable," Enables fcoe on a ethernet interface.");--module_param_call(disable,fcoe_transport_disable,NULL,NULL,S_IWUSR);-__MODULE_PARM_TYPE(disable,"string");-MODULE_PARM_DESC(disable," Disables fcoe on a ethernet interface.");-/* notification function for packets from net device */staticstructnotifier_blocklibfcoe_notifier={.notifier_call=libfcoe_device_notification,
@@ -730,188 +703,6 @@ out_nodev:EXPORT_SYMBOL(fcoe_ctlr_destroy_store);/**-*fcoe_transport_create()-Createafcoeinterface-*@buffer:ThenameoftheEthernetinterfacetocreateon-*@kp:Theassociatedkernelparam-*-*Calledfromsysfs.Thisholdstheft_mutexwhilecallingthe-*registeredfcoetransport'screatefunction.-*-*Returns:0forsuccess-*/-staticintfcoe_transport_create(constchar*buffer,structkernel_param*kp)-{-intrc=-ENODEV;-structnet_device*netdev=NULL;-structfcoe_transport*ft=NULL;-enumfip_statefip_mode=(enumfip_state)(long)kp->arg;--mutex_lock(&ft_mutex);--netdev=fcoe_if_to_netdev(buffer);-if(!netdev){-LIBFCOE_TRANSPORT_DBG("Invalid device %s.\n",buffer);-gotoout_nodev;-}--ft=fcoe_netdev_map_lookup(netdev);-if(ft){-LIBFCOE_TRANSPORT_DBG("transport %s already has existing "-"FCoE instance on %s.\n",-ft->name,netdev->name);-rc=-EEXIST;-gotoout_putdev;-}--ft=fcoe_transport_lookup(netdev);-if(!ft){-LIBFCOE_TRANSPORT_DBG("no FCoE transport found for %s.\n",-netdev->name);-gotoout_putdev;-}--rc=fcoe_add_netdev_mapping(netdev,ft);-if(rc){-LIBFCOE_TRANSPORT_DBG("failed to add new netdev mapping "-"for FCoE transport %s for %s.\n",-ft->name,netdev->name);-gotoout_putdev;-}--/* pass to transport create */-rc=ft->create?ft->create(netdev,fip_mode):-ENODEV;-if(rc)-fcoe_del_netdev_mapping(netdev);--LIBFCOE_TRANSPORT_DBG("transport %s %s to create fcoe on %s.\n",-ft->name,(rc)?"failed":"succeeded",-netdev->name);--out_putdev:-dev_put(netdev);-out_nodev:-mutex_unlock(&ft_mutex);-returnrc;-}--/**-*fcoe_transport_destroy()-DestroyaFCoEinterface-*@buffer:ThenameoftheEthernetinterfacetobedestroyed-*@kp:Theassociatedkernelparameter-*-*Calledfromsysfs.Thisholdstheft_mutexwhilecallingthe-*registeredfcoetransport'sdestroyfunction.-*-*Returns:0forsuccess-*/-staticintfcoe_transport_destroy(constchar*buffer,structkernel_param*kp)-{-intrc=-ENODEV;-structnet_device*netdev=NULL;-structfcoe_transport*ft=NULL;--mutex_lock(&ft_mutex);--netdev=fcoe_if_to_netdev(buffer);-if(!netdev){-LIBFCOE_TRANSPORT_DBG("invalid device %s.\n",buffer);-gotoout_nodev;-}--ft=fcoe_netdev_map_lookup(netdev);-if(!ft){-LIBFCOE_TRANSPORT_DBG("no FCoE transport found for %s.\n",-netdev->name);-gotoout_putdev;-}--/* pass to transport destroy */-rc=ft->destroy?ft->destroy(netdev):-ENODEV;-fcoe_del_netdev_mapping(netdev);-LIBFCOE_TRANSPORT_DBG("transport %s %s to destroy fcoe on %s.\n",-ft->name,(rc)?"failed":"succeeded",-netdev->name);--out_putdev:-dev_put(netdev);-out_nodev:-mutex_unlock(&ft_mutex);-returnrc;-}--/**-*fcoe_transport_disable()-DisablesaFCoEinterface-*@buffer:ThenameoftheEthernetinterfacetobedisabled-*@kp:Theassociatedkernelparameter-*-*Calledfromsysfs.-*-*Returns:0forsuccess-*/-staticintfcoe_transport_disable(constchar*buffer,structkernel_param*kp)-{-intrc=-ENODEV;-structnet_device*netdev=NULL;-structfcoe_transport*ft=NULL;--mutex_lock(&ft_mutex);--netdev=fcoe_if_to_netdev(buffer);-if(!netdev)-gotoout_nodev;--ft=fcoe_netdev_map_lookup(netdev);-if(!ft)-gotoout_putdev;--rc=ft->disable?ft->disable(netdev):-ENODEV;--out_putdev:-dev_put(netdev);-out_nodev:-mutex_unlock(&ft_mutex);--if(rc==-ERESTARTSYS)-returnrestart_syscall();-else-returnrc;-}--/**-*fcoe_transport_enable()-EnablesaFCoEinterface-*@buffer:ThenameoftheEthernetinterfacetobeenabled-*@kp:Theassociatedkernelparameter-*-*Calledfromsysfs.-*-*Returns:0forsuccess-*/-staticintfcoe_transport_enable(constchar*buffer,structkernel_param*kp)-{-intrc=-ENODEV;-structnet_device*netdev=NULL;-structfcoe_transport*ft=NULL;--mutex_lock(&ft_mutex);--netdev=fcoe_if_to_netdev(buffer);-if(!netdev)-gotoout_nodev;--ft=fcoe_netdev_map_lookup(netdev);-if(!ft)-gotoout_putdev;--rc=ft->enable?ft->enable(netdev):-ENODEV;--out_putdev:-dev_put(netdev);-out_nodev:-mutex_unlock(&ft_mutex);-returnrc;-}--/***libfcoe_init()-Initializationroutineforlibfcoe.ko*/staticint__initlibfcoe_init(void)
From: Robert Love <hidden> Date: 2012-09-10 22:59:37
Convert fcoe to use the new fcoe_sysfs create, delete,
enable, disable, start and mode.
Signed-off-by: Robert Love <redacted>
---
drivers/scsi/fcoe/fcoe.c | 229 +++++++++++++++++++++++-----------------------
1 file changed, 115 insertions(+), 114 deletions(-)
@@ -2250,14 +2157,36 @@ static int fcoe_create(struct net_device *netdev, enum fip_state fip_mode)gotoout_nortnl;}+/* add to lports list */+fcoe_hostlist_add(lport);+/* Make this the "master" N_Port */ctlr->lp=lport;/* setup DCB priority attributes. */fcoe_dcb_create(fcoe);-/* add to lports list */-fcoe_hostlist_add(lport);+out_nodev:+rtnl_unlock();+out_nortnl:+mutex_unlock(&fcoe_config_mutex);+returnrc;+}++/**+*fcoe_start()-Startthecontrolleronafcoeinterface+*@cdev:TheFCoEControllerDevicetostart+*+*Returns:0forsuccess+*/+intfcoe_start(structfcoe_ctlr_device*cdev)+{+structfcoe_ctlr*ctlr=fcoe_ctlr_device_priv(cdev);+structfc_lport*lport=ctlr->lp;+intrc=0;++mutex_lock(&fcoe_config_mutex);+rtnl_lock();/* start FIP Discovery and FLOGI */lport->boot_time=jiffies;
On Mon, Sep 10, 2012 at 03:59:14PM -0700, Robert Love wrote:
This patch makes the 'mode' attribute of a
fcoe_ctlr_device writale. This allows the user
to store the mode with with the ctlr will be in.
Possible modes would be 'Fabric', or 'VN2VN'.
The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
Drivers must implement the set_fcoe_ctlr_mode routine
to support this feature.
libfcoe offers an exported routine to set a fcoe_ctlr's
mode.
Signed-off-by: Robert Love <redacted>
The following series implements a move from using module parameters
as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure
was added to the kernel a few cycles ago, this series builds on that work.
It moves the create, vn2vn_create, destroy, enable and disable interfaces
from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/.
These interfaces simply are not module configurations- they are control
interfaces.
A second goal of this series is to change the initialization sequence for
a FCoE device. The result of this series is that interfaces created using
libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following
starting steps-
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
2) Configure the port
- Change mode, set ddp_min, etc...
3) Start the port
- Begins discovery and/or login (depending on mode)
4) Destroy the port
- Logout and free all memory
Robert, Can you please let me now what is the motivation for this change
and what problem are we solving with this approach? Is this primarily to
allow user to set the mode?
I'm concerned that we will be breaking user space compatibility with
this change, as there should be a corresponding fcoemon/fipvlan change
along with this, and existing utilities will not work. Also the way we
start fcoe will be completely different and the user may need to do the
scripting changes, if any.
Thanks,
Bhanu
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me that
it might not be a good example. I belive bonding uses two values per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Series compiled and tested against v3.5. libfcoe.ko compile warning fixed
upstream after v3.5, anyone who compiles this can ignore section mismatch
warning. Also note that a modified fcoemon is needed to use the fcoe system
service against this kernel modification. I'd be happy to provide that
fcoemon code on request.
---
Robert Love (5):
libfcoe, fcoe: Allow user to set a ctlr's mode
libfcoe: Create new libfcoe control interfaces
fcoe: Use new fcoe_sysfs control interface
bnx2fc: Use new fcoe_sysfs control interface
libfcoe, fcoe: Remove libfcoe module parameters
Documentation/ABI/testing/sysfs-bus-fcoe | 51 +++++++
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 98 ++++++++-----
drivers/scsi/fcoe/fcoe.c | 229 +++++++++++++++---------------
drivers/scsi/fcoe/fcoe.h | 9 +
drivers/scsi/fcoe/fcoe_ctlr.c | 24 +++
drivers/scsi/fcoe/fcoe_sysfs.c | 139 ++++++++++++++++++
drivers/scsi/fcoe/fcoe_transport.c | 174 ++++-------------------
include/scsi/fcoe_sysfs.h | 5 +
include/scsi/libfcoe.h | 20 ++-
9 files changed, 445 insertions(+), 304 deletions(-)
The following series implements a move from using module parameters
as control interfaces to /sys/bus/fcoe based interfaces. A sysfs
infrastructure
was added to the kernel a few cycles ago, this series builds on that
work.
It moves the create, vn2vn_create, destroy, enable and disable
interfaces
from /sys/module/libfcoe/parameters/ to various places under
/sys/bus/fcoe/.
These interfaces simply are not module configurations- they are control
interfaces.
A second goal of this series is to change the initialization sequence
for
a FCoE device. The result of this series is that interfaces created
using
libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the
following
starting steps-
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
2) Configure the port
- Change mode, set ddp_min, etc...
3) Start the port
- Begins discovery and/or login (depending on mode)
4) Destroy the port
- Logout and free all memory
Robert, Can you please let me now what is the motivation for this
change and what problem are we solving with this approach? Is this
primarily to allow user to set the mode?
The main problem is that our control interfaces shouldn't be module
parameters. I think of module parameters as things that globally alter
the module.
I also think that moving to a create/configure/start model gives us
more flexibility going forward. We don't have too many FC/FCoE knobs to
tune right now, but if we wanted to add more we don't have a good way
to do it without starting the whole discovery/login process and then
making changes during the discovery/login.
I think the module parameter problem is the justification, but I'm
trying to be comprehensive in coming up with a flexible interface that
will allow us to evolve as well.
I'm concerned that we will be breaking user space compatibility with
this change, as there should be a corresponding fcoemon/fipvlan change
along with this, and existing utilities will not work. Also the way
we start fcoe will be completely different and the user may need to do
the scripting changes, if any.
See the last statement from my initial posting (it's below). I have
patches to modify fcoemon to use these new interfaces. I'd be happy to
share them, I just didn't want to spam this broad of a audience.
Thanks,
Bhanu
quoted
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me
that
it might not be a good example. I belive bonding uses two values
per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Series compiled and tested against v3.5. libfcoe.ko compile warning
fixed
upstream after v3.5, anyone who compiles this can ignore section
mismatch
warning. Also note that a modified fcoemon is needed to use the fcoe
system
service against this kernel modification. I'd be happy to provide that
fcoemon code on request.
The following series implements a move from using module parameters
as control interfaces to /sys/bus/fcoe based interfaces. A sysfs
infrastructure
was added to the kernel a few cycles ago, this series builds on that
work.
It moves the create, vn2vn_create, destroy, enable and disable
interfaces
from /sys/module/libfcoe/parameters/ to various places under
/sys/bus/fcoe/.
These interfaces simply are not module configurations- they are control
interfaces.
A second goal of this series is to change the initialization sequence
for
a FCoE device. The result of this series is that interfaces created
using
libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the
following
starting steps-
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
2) Configure the port
- Change mode, set ddp_min, etc...
3) Start the port
- Begins discovery and/or login (depending on mode)
4) Destroy the port
- Logout and free all memory
Robert, Can you please let me now what is the motivation for this
change and what problem are we solving with this approach? Is this
primarily to allow user to set the mode?
The main problem is that our control interfaces shouldn't be module
parameters. I think of module parameters as things that globally alter
the module.
I also think that moving to a create/configure/start model gives us
more flexibility going forward. We don't have too many FC/FCoE knobs to
tune right now, but if we wanted to add more we don't have a good way
to do it without starting the whole discovery/login process and then
making changes during the discovery/login.
I think the module parameter problem is the justification, but I'm
trying to be comprehensive in coming up with a flexible interface that
will allow us to evolve as well.
quoted
I'm concerned that we will be breaking user space compatibility with
this change, as there should be a corresponding fcoemon/fipvlan change
along with this, and existing utilities will not work. Also the way
we start fcoe will be completely different and the user may need to do
the scripting changes, if any.
See the last statement from my initial posting (it's below). I have
patches to modify fcoemon to use these new interfaces. I'd be happy to
share them, I just didn't want to spam this broad of a audience.
Thanks Robert for the explanation. Appreciate if you could share the
fcoeutils patches also.
As far as I know sysfs doesn't terminate buf with a '\0' before calling
a store method. Does that mean that you are passing a string that is not
'\0'-terminated to a function that expects a '\0'-terminated string ?
Bart.
From: Chris Leech <hidden> Date: 2012-09-11 17:06:29
On Mon, Sep 10, 2012 at 3:59 PM, Robert Love [off-list ref] wrote:
The following series implements a move from using module parameters
as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure
was added to the kernel a few cycles ago, this series builds on that work.
It moves the create, vn2vn_create, destroy, enable and disable interfaces
from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/.
These interfaces simply are not module configurations- they are control
interfaces.
A second goal of this series is to change the initialization sequence for
a FCoE device. The result of this series is that interfaces created using
libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following
starting steps-
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
2) Configure the port
- Change mode, set ddp_min, etc...
3) Start the port
- Begins discovery and/or login (depending on mode)
4) Destroy the port
- Logout and free all memory
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me that
it might not be a good example. I belive bonding uses two values per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Can you give an example session that goes through the 4 steps above
and what the sysfs hierarchy looks like at each step? I mostly get it
from the patch descriptions, but I think it would help discussion of
your proposed interfaces to see an example of them in use.
This feels a little awkward with all the special control files. Have
you thought about something designed for creating kernel objects, like
configfs? Similarly the separate start, enable, disable files vs.
having some sort of status attribute that can take different values.
I feel like these need to be rethought as attributes instead of
triggers. Is there a big difference between start and enable? Can
you achieve the split between create and start by having it come up in
a disabled state by default?
That being said, I'm glad this is being reworked. Do you have any
other functionality in mind that this is laying the groundwork for?
- Chris
From: Chris Leech <cleech@redhat.com> Date: 2012-09-11 17:12:11
On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi
[off-list ref] wrote:
I'm concerned that we will be breaking user space compatibility with this
change, as there should be a corresponding fcoemon/fipvlan change along with
this, and existing utilities will not work. Also the way we start fcoe will
be completely different and the user may need to do the scripting changes,
if any.
I agree with Bhanu on these concerns, even though I hope everyone's
using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a
transition plan than requiring everyone moving to a new kernel to
update the user-space tools at the same time. Removing the module
parameters with the last patch might be rushed, they should probably
remain for a few kernel cycles with a warning. When the tools are
updated for the new interface, they should probably maintain fallback
support for the module parameters for a while as well.
- Chris
2) Configure the port
- Change mode, set ddp_min, etc...
# echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
no visible change
quoted
3) Start the port
- Begins discovery and/or login (depending on mode)
# echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
Begins discovery and login. Assuming there are FCFs then results in:
/sys/bus/fcoe/devices/fcf_0
quoted
4) Destroy the port
- Logout and free all memory
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_destroy
/sys/bus/fcoe/devices/ctlr_0 is removed.
quoted
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me that
it might not be a good example. I belive bonding uses two values per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Can you give an example session that goes through the 4 steps above
and what the sysfs hierarchy looks like at each step? I mostly get it
from the patch descriptions, but I think it would help discussion of
your proposed interfaces to see an example of them in use.
See above. bash-style.
This feels a little awkward with all the special control files. Have
you thought about something designed for creating kernel objects, like
configfs? Similarly the separate start, enable, disable files vs.
Let me do some more reading about configfs. I may not have given it
enough thought.
having some sort of status attribute that can take different values.
I feel like these need to be rethought as attributes instead of
triggers. Is there a big difference between start and enable? Can
you achieve the split between create and start by having it come up in
a disabled state by default?
It's a good idea. I'll look into it.
That being said, I'm glad this is being reworked. Do you have any
other functionality in mind that this is laying the groundwork for?
I have one feature and a few ideas. I currently have a patch that adds
a fabric selection feature. I add another RW attribute to the ctlr_X
device. If the user writes fabric name to the file libfcoe uses it in
it's FCF selection algorithm. Here's my commit message from that patch.
I can share the patch if people would like to see it too. The current
implementation also allows the user to force the login through a
specific FCF.
libfcoe, bnx2fc, fcoe: Add 'selection' attribute
This patch adds a 'selection' attribute to the
fcoe_ctlr_device. The user can write either a
'0x' prefixed fabric name or a ':' separated
MAC address to this file. If a fabric name is
provided the fcoe ctlr will only consider FCFs
with the fabric name when choosing a FCF to login
to. If a MAC address is provided the initiator
will only login to a FCF with the given Ethernet
address. Only one selection is valid at a time.
There are corresponding changes to fcoe-utils
to take advantage of this kernel feature and
to make it more accessible for the user.
To accompany this feature I created a new fipfcf application based on
fipvlan that sends out a discovery solicitation and displays
advertising FCFs.
I've also been talking with Mark Rustad about doing an 'auto' mode
where Fabric discovery is attempted first and if it fails then it tries
VN2VN discovery, but so for we've only had hallway conversations about
it and nothing has been flushed out.
Thanks, //Rob
From: Love, Robert W <hidden> Date: 2012-09-11 17:43:07
On Tue 11 Sep 2012 10:12:09 AM PDT, Chris Leech wrote:
On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi
[off-list ref] wrote:
quoted
I'm concerned that we will be breaking user space compatibility with this
change, as there should be a corresponding fcoemon/fipvlan change along with
this, and existing utilities will not work. Also the way we start fcoe will
be completely different and the user may need to do the scripting changes,
if any.
I agree with Bhanu on these concerns, even though I hope everyone's
using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a
transition plan than requiring everyone moving to a new kernel to
update the user-space tools at the same time. Removing the module
parameters with the last patch might be rushed, they should probably
remain for a few kernel cycles with a warning. When the tools are
updated for the new interface, they should probably maintain fallback
support for the module parameters for a while as well.
Deprecating the old interfaces instead of immediately removing them
sounds like a good idea to me.
I hope everyone is using fcoeadm/fcoemon/fipvlan too. We do still carry
the 'fcc.sh' script in fcoe-utils.git/contrib/. I don't use it, but I
know others do. I did not update 'fcc.sh' with my user space change.
I'll post the fcoemon changes to devel@open-fcoe.org. I think I have a
bunch of cleanup patches that the change depends on, so the series will
probably be half cleanup and half feature.
Thanks, //Rob
From: Love, Robert W <hidden> Date: 2012-09-11 17:46:49
On Tue 11 Sep 2012 10:36:35 AM PDT, Love, Robert W wrote:
On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
quoted
On Mon, Sep 10, 2012 at 3:59 PM, Robert Love [off-list ref] wrote:
<snip>
quoted
That being said, I'm glad this is being reworked. Do you have any
other functionality in mind that this is laying the groundwork for?
I have one feature and a few ideas. I currently have a patch that adds
a fabric selection feature. I add another RW attribute to the ctlr_X
device. If the user writes fabric name to the file libfcoe uses it in
it's FCF selection algorithm. Here's my commit message from that patch.
I can share the patch if people would like to see it too. The current
implementation also allows the user to force the login through a
specific FCF.
My fcoe-utils.git change here also allows the user to drive this fabric
selection using a new variable in the /etc/fcoe/cfg-ethX files that the
'fcoe service' uses.
On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
quoted
On Mon, Sep 10, 2012 at 3:59 PM, Robert Love [off-list ref] wrote:
<snip>
quoted
quoted
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create
I'm assuming the existing functionality of automatically creating the
vlan interface by fcoemon (using the cfg-ethX) continues to exist and
the above is not a replacement for fcoeadm -c.
results in:
/sys/bus/fcoe/devices/ctlr_0/
quoted
quoted
2) Configure the port
- Change mode, set ddp_min, etc...
# echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
no visible change
quoted
quoted
3) Start the port
- Begins discovery and/or login (depending on mode)
# echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
Begins discovery and login. Assuming there are FCFs then results in:
/sys/bus/fcoe/devices/fcf_0
I'm also assuming that the above three steps can be clubbed by
fcoeutils, perhaps by adding 'mode' parameter into the cfg-ethX file.
That way 'service fcoe start' will be no different with the proposed
model, except that there will be multiple entry points into the driver
(alloc, config, start) instead of just one (create).
quoted
quoted
4) Destroy the port
- Logout and free all memory
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_destroy
/sys/bus/fcoe/devices/ctlr_0 is removed.
quoted
quoted
I'm looking for feedback on using sysfs files as control interfaces that
the user (application) would write interface names to. I modeled this
series off of the bonding sysfs interface, but it was suggested to me that
it might not be a good example. I belive bonding uses two values per-file
a '+' or a '-" to add or delete and then the ifname apended. I am simply
writing the ifname to the ctlr_create or ctlr_destroy.
Can you give an example session that goes through the 4 steps above
and what the sysfs hierarchy looks like at each step? I mostly get it
from the patch descriptions, but I think it would help discussion of
your proposed interfaces to see an example of them in use.
See above. bash-style.
quoted
This feels a little awkward with all the special control files. Have
you thought about something designed for creating kernel objects, like
configfs? Similarly the separate start, enable, disable files vs.
Let me do some more reading about configfs. I may not have given it
enough thought.
quoted
having some sort of status attribute that can take different values.
I feel like these need to be rethought as attributes instead of
triggers. Is there a big difference between start and enable? Can
you achieve the split between create and start by having it come up in
a disabled state by default?
It's a good idea. I'll look into it.
quoted
That being said, I'm glad this is being reworked. Do you have any
other functionality in mind that this is laying the groundwork for?
I have one feature and a few ideas. I currently have a patch that adds
a fabric selection feature. I add another RW attribute to the ctlr_X
device. If the user writes fabric name to the file libfcoe uses it in
it's FCF selection algorithm. Here's my commit message from that patch.
I can share the patch if people would like to see it too. The current
implementation also allows the user to force the login through a
specific FCF.
libfcoe, bnx2fc, fcoe: Add 'selection' attribute
This patch adds a 'selection' attribute to the
fcoe_ctlr_device. The user can write either a
'0x' prefixed fabric name or a ':' separated
MAC address to this file. If a fabric name is
provided the fcoe ctlr will only consider FCFs
with the fabric name when choosing a FCF to login
to. If a MAC address is provided the initiator
will only login to a FCF with the given Ethernet
address. Only one selection is valid at a time.
There are corresponding changes to fcoe-utils
to take advantage of this kernel feature and
to make it more accessible for the user.
To accompany this feature I created a new fipfcf application based on
fipvlan that sends out a discovery solicitation and displays
advertising FCFs.
I've also been talking with Mark Rustad about doing an 'auto' mode
where Fabric discovery is attempted first and if it fails then it tries
VN2VN discovery, but so for we've only had hallway conversations about
it and nothing has been flushed out.
Thanks, //Rob�{.n�+�������+%��lzwm��b�맲��r��zX��
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Love, Robert W <hidden> Date: 2012-09-11 18:47:33
On Tue 11 Sep 2012 11:31:08 AM PDT, Bhanu Prakash Gollapudi wrote:
On 9/11/2012 10:36 AM, Love, Robert W wrote:
quoted
On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
quoted
On Mon, Sep 10, 2012 at 3:59 PM, Robert Love
[off-list ref] wrote:
<snip>
quoted
quoted
1) Create/alloc the port
- Allocate kernel memory and create per-instance sysfs devices
- No discovery or login
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create
I'm assuming the existing functionality of automatically creating the
vlan interface by fcoemon (using the cfg-ethX) continues to exist and
the above is not a replacement for fcoeadm -c.
Yes, you're right. These examples are only if you were using the
interfaces from BASH. It's all coded up for fcoemon and there shouldn't
be any user experience change with the new code. I'll post that code to
devel@open-fcoe.org once I get it rebased and quickly tested.
quoted
results in:
/sys/bus/fcoe/devices/ctlr_0/
quoted
quoted
2) Configure the port
- Change mode, set ddp_min, etc...
# echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
no visible change
quoted
quoted
3) Start the port
- Begins discovery and/or login (depending on mode)
# echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
Begins discovery and login. Assuming there are FCFs then results in:
/sys/bus/fcoe/devices/fcf_0
I'm also assuming that the above three steps can be clubbed by
fcoeutils, perhaps by adding 'mode' parameter into the cfg-ethX file.
That way 'service fcoe start' will be no different with the proposed
model, except that there will be multiple entry points into the driver
(alloc, config, start) instead of just one (create).
Yes, you're right here too. However, the default is 'Fabric' so fcoemon
won't actually have to change the mode. However, I'd like to see VN2VN
support added to fcoeadm/fcoemon. It's on the TODO list. Once that's
implemented fcoemon would need to change the mode depending on the
user's selection.
As far as I know sysfs doesn't terminate buf with a '\0' before calling
a store method. Does that mean that you are passing a string that is not
'\0'-terminated to a function that expects a '\0'-terminated string ?
Bart.
Hey Bart. I just wanted to acknowledge your comments. I will make sure
that they're addressed after figuring out if sysfs is the right place
for the interfaces.
Thanks, //Rob
This patch is the first in a series that will remove
libfcoe's create, destroy, enable and disable module
parameters and replace them with interface files in
the new /sys/bus/fcoe subsystem.
Old layout:
/sys/module/libfcoe/parameters/{create,destroy,enable,disable,vn2vn_create}
New layout:
/sys/bus/fcoe/ctlr_{create,destroy}
/sys/bus/fcoe/ctlr_X/{enable,disable,start}
This patch moves fcoe drivers to the following
initialization sequence-
1) create/alloc
2) configure
3) start
A control sysfs interface at /sys/bus/fcoe/ctlr_create
is added. Writing the interface name to this file
will allocate memory and create a sysfs entry for a
new fcoe_ctlr_device. The user may then tune the interface in
any desired way. After configuration the user will
echo any value into the /sys/bus/fcoe/devices/ctlr_X/start
interface to proceed with logging in.
VN2VN logins will still use the module parameters.
A follow up patch to this one will make the 'mode'
attribute of the fcoe_ctlr_device writable. Which will
allow a user to change the ctlr's mode to 'VN2VN'.
Signed-off-by: Robert Love <redacted>
---
Documentation/ABI/testing/sysfs-bus-fcoe | 43 ++++++++++++
drivers/scsi/fcoe/fcoe.h | 9 +++
drivers/scsi/fcoe/fcoe_ctlr.c | 2 -
drivers/scsi/fcoe/fcoe_sysfs.c | 78 ++++++++++++++++++++++
drivers/scsi/fcoe/fcoe_transport.c | 105 +++++++++++++++++++++++++++++-
include/scsi/fcoe_sysfs.h | 4 +
include/scsi/libfcoe.h | 14 ++++
7 files changed, 250 insertions(+), 5 deletions(-)
Robert, what is the reason for initializing it to DISABLED? Unless the
FIP state is FIP_ST_LINK_WAIT, fcoe_ctlr_link_up() doesnt set
lport->link_up and hence does not allow any FIP/FCoE frames to be sent out.
@@ -64,6 +67,7 @@ struct fcoe_ctlr_device {intfcf_dev_loss_tmo;enumfip_conn_typemode;+u8started:1;/* expected in host order for displaying */structfcoe_fc_els_lesblesb;
Convert bnx2fc to use the new fcoe_sysfs create, delete,
enable, disable, start and mode.
bnx2fc doesn't support VN2VN. bnx2fc will not initialize
the set_fcoe_ctlr_mode routine and therefore its instances
will always be in FABRIC mode. There was previously an
explicit check for the ctlr's mode, but this is no longer
needed because not implementing set_fcoe_ctlr_mode implies
that the ctlr cannot change from the FABRIC mode.
Signed-off-by: Robert Love <redacted>
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 98 +++++++++++++++++++++++--------------
1 file changed, 60 insertions(+), 38 deletions(-)
I think more changes are required for bnx2fc as fc_lport_init() is
called just before calling fc_fabric_login() - whcih is called during
'start'. Because of this, if we just call 'create' followed by 'destroy'
without calling 'start', lport is not initialized and I expect to see
some panics when destroy is called.
Let me try testing your patches and send you any fixes that are required.