RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Friday, March 18, 2016 3:41 PM
> To: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen
> <martin.peter...@oracle.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> On Thu, 2016-03-17 at 00:01 +, KY Srinivasan wrote:
> > The only attributes I would be interested are:
> > 1) node name
> > 2) port name
> >
> > Ideally, if this can show under /sys/class/fc_host/hostx/port_name
> > and node_name,
> > it will be ideal since all user scripts can work.
> 
> OK, like this?
> 
> From 7af7c428e7e04ddcc87fda12d6571e3dff8ae024 Mon Sep 17 00:00:00
> 2001
> From: James Bottomley <james.bottom...@hansenpartnership.com>
> Date: Fri, 18 Mar 2016 15:35:45 -0700
> Subject: scsi_transport_fc: introduce lightweight class for virtualization
>  systems
> 
> The FC transport class is very heavily tilted towards helping things
> which operate a fabric (as it should be).  However, there seems to be
> a need for a lightweight version for use in virtual systems that
> simply want to show pass through FC information without making any use
> of the heavyweight functions.  This is an attempt to give them what
> they want: the lightweight class has no vports or rports and only two
> host attributes.  Essentially, it's designed for the HV storvsc
> driver, but if other virtualizataion systems have similar problems, we
> can add more attributes.
> 
> Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com>
> ---
>  drivers/scsi/scsi_transport_fc.c | 94
> 
>  include/scsi/scsi_transport_fc.h |  3 ++
>  2 files changed, 97 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_fc.c 
> b/drivers/scsi/scsi_transport_fc.c
> index 8a88226..a9fcb4d 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -351,6 +351,27 @@ struct fc_internal {
> 
>  #define to_fc_internal(tmpl) container_of(tmpl, struct fc_internal, t)
> 
> +#define FC_LW_HOST_NUM_ATTRS 2
> +struct fc_lw_internal {
> + struct scsi_transport_template t;
> + struct fc_function_template *f;
> +
> + /*
> +  * For attributes : each object has :
> +  *   An array of the actual attributes structures
> +  *   An array of null-terminated pointers to the attribute
> +  * structures - used for mid-layer interaction.
> +  *
> +  * The attribute containers for the starget and host are are
> +  * part of the midlayer. As the remote port is specific to the
> +  * fc transport, we must provide the attribute container.
> +  */
> + struct device_attribute
> private_host_attrs[FC_LW_HOST_NUM_ATTRS];
> + struct device_attribute *host_attrs[FC_LW_HOST_NUM_ATTRS + 1];
> +};
> +
> +#define to_fc_lw_internal(tmpl)  container_of(tmpl, struct
> fc_lw_internal, t)
> +
>  static int fc_target_setup(struct transport_container *tc, struct device 
> *dev,
>  struct device *cdev)
>  {
> @@ -472,6 +493,12 @@ static int fc_host_remove(struct transport_container
> *tc, struct device *dev,
>   return 0;
>  }
> 
> +static DECLARE_TRANSPORT_CLASS(fc_lw_host_class,
> +"fc_host",
> +NULL,
> +NULL,
> +NULL);
> +
>  static DECLARE_TRANSPORT_CLASS(fc_host_class,
>  "fc_host",
>  fc_host_setup,
> @@ -1968,6 +1995,25 @@ static int fc_host_match(struct
> attribute_container *cont,
>   return >t.host_attrs.ac == cont;
>  }
> 
> +static int fc_lw_host_match(struct attribute_container *cont,
> +   struct device *dev)
> +{
> + struct Scsi_Host *shost;
> + struct fc_lw_internal *i;
> +
> + if (!scsi_is_host_device(dev))
> + return 0;
> +
> + shost = dev_to_shost(dev);
> + if (!shost->transportt  || shost->transportt->host_attrs.ac.class
> + != _lw_host_class.class)
> + return 0;
> +
> + i = to_fc_lw_internal(shost->transportt);
> +
> + return >t.host_attrs.ac == cont;
> +}
> +
>  static int fc_target_match(st

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: KY Srinivasan
> Sent: Sunday, March 20, 2016 11:59 AM
> To: 'James Bottomley' <james.bottom...@hansenpartnership.com>; Martin
> K. Petersen <martin.peter...@oracle.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> h...@suse.de
> Subject: RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> 
> 
> > -Original Message-
> > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com]
> > Sent: Friday, March 18, 2016 3:41 PM
> > To: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen
> > <martin.peter...@oracle.com>
> > Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> > linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > h...@suse.de
> > Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> > Hyper-V
> >
> > On Thu, 2016-03-17 at 00:01 +, KY Srinivasan wrote:
> > > The only attributes I would be interested are:
> > > 1) node name
> > > 2) port name
> > >
> > > Ideally, if this can show under /sys/class/fc_host/hostx/port_name
> > > and node_name,
> > > it will be ideal since all user scripts can work.
> >
> > OK, like this?
> 
> Yes; thank you very much James. Looking at the patch though, it may be an
> overkill considering how much of the code is duplicated. The current fc
> transport
> class does give us the flexibility to control the attributes we want to 
> surface
> (fc_function_template). In any case I will test this code and get back to you
> soon.

Today I got a chance to test this patch. Looks like all the state is not getting
properly set in this new transport class. I am hitting this NULL pointer 
reference fault in
get_device_parent(). Looks like the device class is not properly setup for
this transport class. class_dir_create_and_add() is not called for this class
and so the glue_dirs is NULL.   I fixed the issue:

1) You will need to call the transport_class_register() for this new transport 
class in
fc_transport_init()
2) We cannot use fc_host as the name in this new class since the standard fc 
transport already
Uses that name. I changed the name to get this to work. This will create a new 
directory under /sys/class.
So my original goal of  being compatible with existing scripts that expect to 
find the information under
/sys/class/fc_host will not be met.

Regards,

K. Y


> 
> Regards,
> 
> K. Y
> 
> 
> >
> > From 7af7c428e7e04ddcc87fda12d6571e3dff8ae024 Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley <james.bottom...@hansenpartnership.com>
> > Date: Fri, 18 Mar 2016 15:35:45 -0700
> > Subject: scsi_transport_fc: introduce lightweight class for virtualization
> >  systems
> >
> > The FC transport class is very heavily tilted towards helping things
> > which operate a fabric (as it should be).  However, there seems to be
> > a need for a lightweight version for use in virtual systems that
> > simply want to show pass through FC information without making any use
> > of the heavyweight functions.  This is an attempt to give them what
> > they want: the lightweight class has no vports or rports and only two
> > host attributes.  Essentially, it's designed for the HV storvsc
> > driver, but if other virtualizataion systems have similar problems, we
> > can add more attributes.
> >
> > Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com>
> > ---
> >  drivers/scsi/scsi_transport_fc.c | 94
> > 
> >  include/scsi/scsi_transport_fc.h |  3 ++
> >  2 files changed, 97 insertions(+)
> >
> > diff --git a/drivers/scsi/scsi_transport_fc.c
> b/drivers/scsi/scsi_transport_fc.c
> > index 8a88226..a9fcb4d 100644
> > --- a/drivers/scsi/scsi_transport_fc.c
> > +++ b/drivers/scsi/scsi_transport_fc.c
> > @@ -351,6 +351,27 @@ struct fc_internal {
> >
> >  #define to_fc_internal(tmpl)   container_of(tmpl, struct fc_internal, 
> > t)
> >
> > +#define FC_LW_HOST_NUM_ATTRS   2
> > +struct fc_lw_internal {
> > +   struct scsi_transport_template t;
> > +   struct fc_function_template *f;
> > +
> > +   /*
> > + 

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Friday, March 18, 2016 3:41 PM
> To: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen
> <martin.peter...@oracle.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> On Thu, 2016-03-17 at 00:01 +, KY Srinivasan wrote:
> > The only attributes I would be interested are:
> > 1) node name
> > 2) port name
> >
> > Ideally, if this can show under /sys/class/fc_host/hostx/port_name
> > and node_name,
> > it will be ideal since all user scripts can work.
> 
> OK, like this?

Yes; thank you very much James. Looking at the patch though, it may be an 
overkill considering how much of the code is duplicated. The current fc 
transport
class does give us the flexibility to control the attributes we want to surface
(fc_function_template). In any case I will test this code and get back to you 
soon.

Regards,

K. Y

 
> 
> From 7af7c428e7e04ddcc87fda12d6571e3dff8ae024 Mon Sep 17 00:00:00
> 2001
> From: James Bottomley <james.bottom...@hansenpartnership.com>
> Date: Fri, 18 Mar 2016 15:35:45 -0700
> Subject: scsi_transport_fc: introduce lightweight class for virtualization
>  systems
> 
> The FC transport class is very heavily tilted towards helping things
> which operate a fabric (as it should be).  However, there seems to be
> a need for a lightweight version for use in virtual systems that
> simply want to show pass through FC information without making any use
> of the heavyweight functions.  This is an attempt to give them what
> they want: the lightweight class has no vports or rports and only two
> host attributes.  Essentially, it's designed for the HV storvsc
> driver, but if other virtualizataion systems have similar problems, we
> can add more attributes.
> 
> Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com>
> ---
>  drivers/scsi/scsi_transport_fc.c | 94
> 
>  include/scsi/scsi_transport_fc.h |  3 ++
>  2 files changed, 97 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_fc.c 
> b/drivers/scsi/scsi_transport_fc.c
> index 8a88226..a9fcb4d 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -351,6 +351,27 @@ struct fc_internal {
> 
>  #define to_fc_internal(tmpl) container_of(tmpl, struct fc_internal, t)
> 
> +#define FC_LW_HOST_NUM_ATTRS 2
> +struct fc_lw_internal {
> + struct scsi_transport_template t;
> + struct fc_function_template *f;
> +
> + /*
> +  * For attributes : each object has :
> +  *   An array of the actual attributes structures
> +  *   An array of null-terminated pointers to the attribute
> +  * structures - used for mid-layer interaction.
> +  *
> +  * The attribute containers for the starget and host are are
> +  * part of the midlayer. As the remote port is specific to the
> +  * fc transport, we must provide the attribute container.
> +  */
> + struct device_attribute
> private_host_attrs[FC_LW_HOST_NUM_ATTRS];
> + struct device_attribute *host_attrs[FC_LW_HOST_NUM_ATTRS + 1];
> +};
> +
> +#define to_fc_lw_internal(tmpl)  container_of(tmpl, struct
> fc_lw_internal, t)
> +
>  static int fc_target_setup(struct transport_container *tc, struct device 
> *dev,
>  struct device *cdev)
>  {
> @@ -472,6 +493,12 @@ static int fc_host_remove(struct transport_container
> *tc, struct device *dev,
>   return 0;
>  }
> 
> +static DECLARE_TRANSPORT_CLASS(fc_lw_host_class,
> +"fc_host",
> +NULL,
> +NULL,
> +NULL);
> +
>  static DECLARE_TRANSPORT_CLASS(fc_host_class,
>  "fc_host",
>  fc_host_setup,
> @@ -1968,6 +1995,25 @@ static int fc_host_match(struct
> attribute_container *cont,
>   return >t.host_attrs.ac == cont;
>  }
> 
> +static int fc_lw_host_match(struct attribute_container *cont,
> +   struct device *dev)
> +{
> + struct Scsi_Host *shost;
> + struct fc_lw_internal *i;
> +
> + if (!scsi_is_host_device(dev))
> + return 0;
> +
> + shost =

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Wednesday, March 16, 2016 4:41 PM
> To: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen
> <martin.peter...@oracle.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> On Wed, 2016-03-16 at 23:15 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com
> > > ]
> > > Sent: Wednesday, March 16, 2016 4:08 PM
> > > To: Martin K. Petersen <martin.peter...@oracle.com>; KY Srinivasan
> > > <k...@microsoft.com>
> > > Cc: Christoph Hellwig <h...@infradead.org>;
> > > gre...@linuxfoundation.org;
> > > linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > oher...@suse.com; jbottom...@parallels.com;
> > > linux-s...@vger.kernel.org;
> > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > h...@suse.de
> > > Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC
> > > hosts on
> > > Hyper-V
> > >
> > > On Wed, 2016-03-16 at 18:34 -0400, Martin K. Petersen wrote:
> > > > > > > > > "KY" == KY Srinivasan <k...@microsoft.com> writes:
> > > >
> > > > KY> How would I get the sysfs files under fc_host if I don't use
> > > > the
> > > > FC
> > > > KY> transport.  The customer scripts expect these sysfs files.
> > > >
> > > > Right, but I was interested in finding out why they need those
> > > > files. And whether an alternative to the FC transport would be a
> > > > better solution.
> > >
> > > If it's just the wwn file (or a set of other values), we might be
> > > able
> > > to separate that bit out of the FC transport class so you can use
> > > it
> > > independently ... do you have a full list of the files being used?
> >
> > Wwn files are what we can support on Hyper-V and that is what I want
> > to support (to address customer requirements).
> 
> There is no wwn file.  These are all the possible attributes they could
> use; which one(s) do you want:
> 
>   /*
>* Setup SCSI Host Attributes.
>*/
>   SETUP_HOST_ATTRIBUTE_RD(node_name);
>   SETUP_HOST_ATTRIBUTE_RD(port_name);
>   SETUP_HOST_ATTRIBUTE_RD(permanent_port_name);
>   SETUP_HOST_ATTRIBUTE_RD(supported_classes);
>   SETUP_HOST_ATTRIBUTE_RD(supported_fc4s);
>   SETUP_HOST_ATTRIBUTE_RD(supported_speeds);
>   SETUP_HOST_ATTRIBUTE_RD(maxframe_size);
>   if (ft->vport_create) {
>   SETUP_HOST_ATTRIBUTE_RD_NS(max_npiv_vports);
>   SETUP_HOST_ATTRIBUTE_RD_NS(npiv_vports_inuse);
>   }
>   SETUP_HOST_ATTRIBUTE_RD(serial_number);
>   SETUP_HOST_ATTRIBUTE_RD(manufacturer);
>   SETUP_HOST_ATTRIBUTE_RD(model);
>   SETUP_HOST_ATTRIBUTE_RD(model_description);
>   SETUP_HOST_ATTRIBUTE_RD(hardware_version);
>   SETUP_HOST_ATTRIBUTE_RD(driver_version);
>   SETUP_HOST_ATTRIBUTE_RD(firmware_version);
>   SETUP_HOST_ATTRIBUTE_RD(optionrom_version);
> 
>   SETUP_HOST_ATTRIBUTE_RD(port_id);
>   SETUP_HOST_ATTRIBUTE_RD(port_type);
>   SETUP_HOST_ATTRIBUTE_RD(port_state);
>   SETUP_HOST_ATTRIBUTE_RD(active_fc4s);
>   SETUP_HOST_ATTRIBUTE_RD(speed);
>   SETUP_HOST_ATTRIBUTE_RD(fabric_name);
>   SETUP_HOST_ATTRIBUTE_RD(symbolic_name);
>   SETUP_HOST_ATTRIBUTE_RW(system_hostname);
> 
>   /* Transport-managed attributes */
>   SETUP_PRIVATE_HOST_ATTRIBUTE_RW(dev_loss_tmo);
>   SETUP_PRIVATE_HOST_ATTRIBUTE_RW(tgtid_bind_type);
>   if (ft->issue_fc_host_lip)
>   SETUP_PRIVATE_HOST_ATTRIBUTE_RW(issue_lip);
>   if (ft->vport_create)
>   SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_create);
>   if (ft->vport_delete)
>   SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_delete);
>   /*
>* Setup Remote Port Attributes.
>*/
>   count=0;
>   SETUP_RPORT_ATTRIBUTE_RD(maxframe_size);
>   SETUP_RPORT_ATTRIBUTE_RD(supported_classes);
>   SETUP_RPORT_ATTRIBUTE_RW(dev_loss_tmo);
>

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[Martin K. Petersen]

> "KY" == KY Srinivasan  writes:

KY> How would I get the sysfs files under fc_host if I don't use the FC
KY> transport.  The customer scripts expect these sysfs files.

Right, but I was interested in finding out why they need those
files. And whether an alternative to the FC transport would be a better
solution.

-- 
Martin K. Petersen  Oracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[James Bottomley]

On Wed, 2016-03-16 at 18:34 -0400, Martin K. Petersen wrote:
> > > > > > "KY" == KY Srinivasan  writes:
> 
> KY> How would I get the sysfs files under fc_host if I don't use the
> FC
> KY> transport.  The customer scripts expect these sysfs files.
> 
> Right, but I was interested in finding out why they need those
> files. And whether an alternative to the FC transport would be a 
> better solution.

If it's just the wwn file (or a set of other values), we might be able
to separate that bit out of the FC transport class so you can use it
independently ... do you have a full list of the files being used?

Thanks,

James

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Wednesday, March 16, 2016 4:08 PM
> To: Martin K. Petersen <martin.peter...@oracle.com>; KY Srinivasan
> <k...@microsoft.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> On Wed, 2016-03-16 at 18:34 -0400, Martin K. Petersen wrote:
> > > > > > > "KY" == KY Srinivasan <k...@microsoft.com> writes:
> >
> > KY> How would I get the sysfs files under fc_host if I don't use the
> > FC
> > KY> transport.  The customer scripts expect these sysfs files.
> >
> > Right, but I was interested in finding out why they need those
> > files. And whether an alternative to the FC transport would be a
> > better solution.
> 
> If it's just the wwn file (or a set of other values), we might be able
> to separate that bit out of the FC transport class so you can use it
> independently ... do you have a full list of the files being used?

Wwn files are what we can support on Hyper-V and that is what I want to support
(to address customer requirements).

Regards,

K. Y 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[James Bottomley]

On Wed, 2016-03-16 at 23:15 +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com
> > ]
> > Sent: Wednesday, March 16, 2016 4:08 PM
> > To: Martin K. Petersen <martin.peter...@oracle.com>; KY Srinivasan
> > <k...@microsoft.com>
> > Cc: Christoph Hellwig <h...@infradead.org>; 
> > gre...@linuxfoundation.org;
> > linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > oher...@suse.com; jbottom...@parallels.com; 
> > linux-s...@vger.kernel.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > h...@suse.de
> > Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC
> > hosts on
> > Hyper-V
> > 
> > On Wed, 2016-03-16 at 18:34 -0400, Martin K. Petersen wrote:
> > > > > > > > "KY" == KY Srinivasan <k...@microsoft.com> writes:
> > > 
> > > KY> How would I get the sysfs files under fc_host if I don't use
> > > the
> > > FC
> > > KY> transport.  The customer scripts expect these sysfs files.
> > > 
> > > Right, but I was interested in finding out why they need those
> > > files. And whether an alternative to the FC transport would be a
> > > better solution.
> > 
> > If it's just the wwn file (or a set of other values), we might be
> > able
> > to separate that bit out of the FC transport class so you can use
> > it
> > independently ... do you have a full list of the files being used?
> 
> Wwn files are what we can support on Hyper-V and that is what I want 
> to support (to address customer requirements).

There is no wwn file.  These are all the possible attributes they could
use; which one(s) do you want:

/*
 * Setup SCSI Host Attributes.
 */
SETUP_HOST_ATTRIBUTE_RD(node_name);
SETUP_HOST_ATTRIBUTE_RD(port_name);
SETUP_HOST_ATTRIBUTE_RD(permanent_port_name);
SETUP_HOST_ATTRIBUTE_RD(supported_classes);
SETUP_HOST_ATTRIBUTE_RD(supported_fc4s);
SETUP_HOST_ATTRIBUTE_RD(supported_speeds);
SETUP_HOST_ATTRIBUTE_RD(maxframe_size);
if (ft->vport_create) {
SETUP_HOST_ATTRIBUTE_RD_NS(max_npiv_vports);
SETUP_HOST_ATTRIBUTE_RD_NS(npiv_vports_inuse);
}
SETUP_HOST_ATTRIBUTE_RD(serial_number);
SETUP_HOST_ATTRIBUTE_RD(manufacturer);
SETUP_HOST_ATTRIBUTE_RD(model);
SETUP_HOST_ATTRIBUTE_RD(model_description);
SETUP_HOST_ATTRIBUTE_RD(hardware_version);
SETUP_HOST_ATTRIBUTE_RD(driver_version);
SETUP_HOST_ATTRIBUTE_RD(firmware_version);
SETUP_HOST_ATTRIBUTE_RD(optionrom_version);

SETUP_HOST_ATTRIBUTE_RD(port_id);
SETUP_HOST_ATTRIBUTE_RD(port_type);
SETUP_HOST_ATTRIBUTE_RD(port_state);
SETUP_HOST_ATTRIBUTE_RD(active_fc4s);
SETUP_HOST_ATTRIBUTE_RD(speed);
SETUP_HOST_ATTRIBUTE_RD(fabric_name);
SETUP_HOST_ATTRIBUTE_RD(symbolic_name);
SETUP_HOST_ATTRIBUTE_RW(system_hostname);

/* Transport-managed attributes */
SETUP_PRIVATE_HOST_ATTRIBUTE_RW(dev_loss_tmo);
SETUP_PRIVATE_HOST_ATTRIBUTE_RW(tgtid_bind_type);
if (ft->issue_fc_host_lip)
SETUP_PRIVATE_HOST_ATTRIBUTE_RW(issue_lip);
if (ft->vport_create)
SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_create);
if (ft->vport_delete)
SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_delete);
/*
 * Setup Remote Port Attributes.
 */
count=0;
SETUP_RPORT_ATTRIBUTE_RD(maxframe_size);
SETUP_RPORT_ATTRIBUTE_RD(supported_classes);
SETUP_RPORT_ATTRIBUTE_RW(dev_loss_tmo);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(node_name);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(port_name);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(port_id);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(roles);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(port_state);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RD(scsi_target_id);
SETUP_PRIVATE_RPORT_ATTRIBUTE_RW(fast_io_fail_tmo);

/*
 * Setup Virtual Port Attributes.
 */
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_state);
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_last_state);
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(node_name);
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(port_name);
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(roles);
SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_type);
SETUP_VPORT_ATTRIBUTE_RW(symbolic_name);
SETUP_VPORT_ATTRIBUTE_WR(vport_delete);
SETUP_VPORT_ATTRIBUTE_WR(vport_disable);

I'm assuming it's host and rport port_id?

James


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[James Bottomley]

On Thu, 2016-03-17 at 00:01 +, KY Srinivasan wrote:
> The only attributes I would be interested are:
> 1) node name
> 2) port name
> 
> Ideally, if this can show under /sys/class/fc_host/hostx/port_name
> and node_name,
> it will be ideal since all user scripts can work.

OK, like this?

>From 7af7c428e7e04ddcc87fda12d6571e3dff8ae024 Mon Sep 17 00:00:00 2001
From: James Bottomley 
Date: Fri, 18 Mar 2016 15:35:45 -0700
Subject: scsi_transport_fc: introduce lightweight class for virtualization
 systems

The FC transport class is very heavily tilted towards helping things
which operate a fabric (as it should be).  However, there seems to be
a need for a lightweight version for use in virtual systems that
simply want to show pass through FC information without making any use
of the heavyweight functions.  This is an attempt to give them what
they want: the lightweight class has no vports or rports and only two
host attributes.  Essentially, it's designed for the HV storvsc
driver, but if other virtualizataion systems have similar problems, we
can add more attributes.

Signed-off-by: James Bottomley 
---
 drivers/scsi/scsi_transport_fc.c | 94 
 include/scsi/scsi_transport_fc.h |  3 ++
 2 files changed, 97 insertions(+)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 8a88226..a9fcb4d 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -351,6 +351,27 @@ struct fc_internal {
 
 #define to_fc_internal(tmpl)   container_of(tmpl, struct fc_internal, t)
 
+#define FC_LW_HOST_NUM_ATTRS   2
+struct fc_lw_internal {
+   struct scsi_transport_template t;
+   struct fc_function_template *f;
+
+   /*
+* For attributes : each object has :
+*   An array of the actual attributes structures
+*   An array of null-terminated pointers to the attribute
+* structures - used for mid-layer interaction.
+*
+* The attribute containers for the starget and host are are
+* part of the midlayer. As the remote port is specific to the
+* fc transport, we must provide the attribute container.
+*/
+   struct device_attribute private_host_attrs[FC_LW_HOST_NUM_ATTRS];
+   struct device_attribute *host_attrs[FC_LW_HOST_NUM_ATTRS + 1];
+};
+
+#define to_fc_lw_internal(tmpl)container_of(tmpl, struct 
fc_lw_internal, t)
+
 static int fc_target_setup(struct transport_container *tc, struct device *dev,
   struct device *cdev)
 {
@@ -472,6 +493,12 @@ static int fc_host_remove(struct transport_container *tc, 
struct device *dev,
return 0;
 }
 
+static DECLARE_TRANSPORT_CLASS(fc_lw_host_class,
+  "fc_host",
+  NULL,
+  NULL,
+  NULL);
+
 static DECLARE_TRANSPORT_CLASS(fc_host_class,
   "fc_host",
   fc_host_setup,
@@ -1968,6 +1995,25 @@ static int fc_host_match(struct attribute_container 
*cont,
return >t.host_attrs.ac == cont;
 }
 
+static int fc_lw_host_match(struct attribute_container *cont,
+ struct device *dev)
+{
+   struct Scsi_Host *shost;
+   struct fc_lw_internal *i;
+
+   if (!scsi_is_host_device(dev))
+   return 0;
+
+   shost = dev_to_shost(dev);
+   if (!shost->transportt  || shost->transportt->host_attrs.ac.class
+   != _lw_host_class.class)
+   return 0;
+
+   i = to_fc_lw_internal(shost->transportt);
+
+   return >t.host_attrs.ac == cont;
+}
+
 static int fc_target_match(struct attribute_container *cont,
struct device *dev)
 {
@@ -2171,6 +2217,54 @@ static int fc_it_nexus_response(struct Scsi_Host *shost, 
u64 nexus, int result)
return i->f->it_nexus_response(shost, nexus, result);
 }
 
+/**
+ * fc_attach_lw_transport - light weight attach function
+ * @ft:function template for optional attributes
+ *
+ * This attach function is to be used only for virtual FC emulators
+ * which do not have a physical fabric underneath them and thus only
+ * need a few attributes and no helper functions
+ */
+struct scsi_transport_template *
+fc_lw_attach_transport(struct fc_function_template *ft)
+{
+   int count;
+   struct fc_lw_internal *i = kzalloc(sizeof(struct fc_lw_internal),
+  GFP_KERNEL);
+
+   if (unlikely(!i))
+   return NULL;
+
+   i->t.host_attrs.ac.attrs = >host_attrs[0];
+   i->t.host_attrs.ac.class = _lw_host_class.class;
+   i->t.host_attrs.ac.match = fc_lw_host_match;
+   i->t.host_size = sizeof(struct fc_host_attrs);
+   transport_container_register(>t.host_attrs);
+
+   i->f = ft;
+
+   count = 0;
+   

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, March 15, 2016 2:25 PM
> To: KY Srinivasan <k...@microsoft.com>
> Cc: Christoph Hellwig <h...@infradead.org>; gre...@linuxfoundation.org;
> linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> >>>>> "KY" == KY Srinivasan <k...@microsoft.com> writes:
> 
> KY> Till recently I had not. However, we do support publishing wwn in
> KY> the guest and some customers wanted this. That is the reason I am
> KY> attaching FC transport and working through the issues. With this
> KY> change, I now have wwn names published in the guest and I can also
> KY> issue manual scan.
> 
> Why does it have to look like FC? Will a device identification VPD page
> not do the trick?

How would I get the sysfs files under fc_host if I don't use the FC transport.
The customer scripts expect these sysfs files.

Regards,

K. Y
> 
> --
> Martin K. PetersenOracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[Martin K. Petersen]

> "KY" == KY Srinivasan  writes:

KY> Till recently I had not. However, we do support publishing wwn in
KY> the guest and some customers wanted this. That is the reason I am
KY> attaching FC transport and working through the issues. With this
KY> change, I now have wwn names published in the guest and I can also
KY> issue manual scan.

Why does it have to look like FC? Will a device identification VPD page
not do the trick?

-- 
Martin K. Petersen  Oracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[KY Srinivasan]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Tuesday, March 15, 2016 6:40 AM
> To: KY Srinivasan <k...@microsoft.com>
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on
> Hyper-V
> 
> On Sat, Mar 12, 2016 at 01:52:48PM -0800, K. Y. Srinivasan wrote:
> > The default user scan function associated with FC (fc_user_scan)
> > is not suitable for FC hosts on Hyper-V since we don't have
> > an rport associated with FC host on Hyper-V . Set it to NULL so we can
> > support manual scan of FC targets on Hyper-V.
> 
> This isn't really how the FC transport class in intended to work, but
> neither is the eh_timed_out (which I haven't seen in my tree yet).
> 
> It sounds like storvsc simply shouldn't attach to the FC transport
> if it doesn't actually look like a FC HBA.

Till recently I had not. However, we do support publishing wwn in the guest and
some customers wanted this. That is the reason I am attaching FC transport and 
working
through the issues. With this change, I now have wwn names published in the 
guest and I can
also issue manual scan.


Regards,

K. Y 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[Christoph Hellwig]

On Sat, Mar 12, 2016 at 01:52:48PM -0800, K. Y. Srinivasan wrote:
> The default user scan function associated with FC (fc_user_scan)
> is not suitable for FC hosts on Hyper-V since we don't have
> an rport associated with FC host on Hyper-V . Set it to NULL so we can
> support manual scan of FC targets on Hyper-V.

This isn't really how the FC transport class in intended to work, but
neither is the eh_timed_out (which I haven't seen in my tree yet).

It sounds like storvsc simply shouldn't attach to the FC transport
if it doesn't actually look like a FC HBA.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

[K. Y. Srinivasan]

The default user scan function associated with FC (fc_user_scan)
is not suitable for FC hosts on Hyper-V since we don't have
an rport associated with FC host on Hyper-V . Set it to NULL so we can
support manual scan of FC targets on Hyper-V.

Signed-off-by: K. Y. Srinivasan 
Tested-by: Long Li 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 132b168..8aec590 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1776,6 +1776,12 @@ static int __init storvsc_drv_init(void)
 * Install Hyper-V specific timeout handler.
 */
fc_transport_template->eh_timed_out = storvsc_eh_timed_out;
+   /*
+* The default user scan function associated with FC (fc_user_scan)
+* is not suitable for FC hosts on Hyper-V. Set it to NULL so we can
+* support manual scan of FC targets on Hyper-V.
+*/
+   fc_transport_template->user_scan = NULL;
 #endif
 
ret = vmbus_driver_register(_drv);
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel