From: Christoph Hellwig <hch@infradead.org>
To: Cathy Avery <cavery@redhat.com>
Cc: kys@microsoft.com, hch@infradead.org, haiyangz@microsoft.com,
jejb@linux.vnet.ibm.com, martin.petersen@oracle.com,
dan.carpenter@oracle.com, devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
famz@redhat.com
Subject: Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.
Date: Thu, 26 Jan 2017 06:51:59 -0800 [thread overview]
Message-ID: <20170126145159.GA29683@infradead.org> (raw)
In-Reply-To: <1485437940-18706-1-git-send-email-cavery@redhat.com>
On Thu, Jan 26, 2017 at 08:38:58AM -0500, Cathy Avery wrote:
> Included in the current storvsc driver for Hyper-V is the ability
> to access luns on an FC fabric via a virtualized fiber channel
> adapter exposed by the Hyper-V host. This was done to provide an
> interface for existing customer tools that was more consistent with
> a conventional FC device. The driver attaches to the FC transport
> to allow host and port names to be published under
> /sys/class/fc_host/hostX.
>
> A problem arose when attaching to the FC transport. The scsi_scan code
> attempts to call fc_user_scan which has basically become a no-op
> due to the virtualized nature of the FC host
> ( missing rports, vports, etc ). At this point you cannot refresh
> the scsi bus after mapping or unmapping luns on the SAN without
> a reboot.
I don't think a device without rports or vports is a FC device, plain and
simple. So as far as I'm concerned we should remove the code from storvsc
that pretends to be FC, and not add it to virtio to start with.
And again I think leightweight is a very confusing name -
what exactly is leight or heavy? It's really fake or dummy
in the current version.
>
> 2) Removes an original workaround dealing with replacing
> the eh_timed_out function. Patch 1 will not set the
> scsi_transport_template.eh_timed_out function directly during
> lightweight fc_attach_transport(). It instead relies on
> whatever was indicated as the scsi_host_template timeout handler
> during scsi_times_out() scsi_error.c. So the workaround is
> no longer necessary.
Can you send a patch that gets rid of the transport class timeout handler
entirely? I think it's simply the wrong layering we have here - the
driver needs to be in control of timeouts, and if it wants it can
optionally call into library code in the transport class.
FYI, all the long-term relevant explanation need to go into the patches
themselves (patch description or code comments), not in the cover
letter.
next prev parent reply other threads:[~2017-01-26 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 13:38 [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host Cathy Avery
2017-01-26 13:38 ` [PATCH v2 1/2] scsi: scsi_transport_fc: Provide a lightweight option for Virtual FC Hosts Cathy Avery
2017-01-26 13:39 ` [PATCH v2 2/2] scsi: storvsc: Add support for FC lightweight host Cathy Avery
2017-01-26 14:51 ` Christoph Hellwig [this message]
2017-01-29 0:35 ` [PATCH v2 0/2] " KY Srinivasan
2017-01-29 8:56 ` Christoph Hellwig
2017-01-30 22:55 ` KY Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126145159.GA29683@infradead.org \
--to=hch@infradead.org \
--cc=cavery@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@linuxdriverproject.org \
--cc=famz@redhat.com \
--cc=haiyangz@microsoft.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).