From: Steffen Maier <maier@linux.vnet.ibm.com>
To: linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Cc: linux-s390@vger.kernel.org,
Steffen Maier <maier@linux.vnet.ibm.com>,
Benjamin Block <bblock@linux.vnet.ibm.com>
Subject: [RFC 0/9] zfcp: decouple scsi_eh callbacks from scsi_cmnd
Date: Tue, 25 Jul 2017 16:14:18 +0200 [thread overview]
Message-ID: <20170725141427.35258-1-maier@linux.vnet.ibm.com> (raw)
This is an early request for comments.
The patch set serves as a zfcp preparation step for Hannes' series
"[PATCH 00/47] SCSI EH argument reshuffle part II"
http://www.spinics.net/lists/linux-scsi/msg111165.html
or
http://marc.info/?l=linux-scsi&m=150091945302995&w=2
The series is based on 18 preceding zfcp patches,
including some stable regression bugfixes for zfcp tracing.
Hence it might not apply cleanly.
However, we plan to post the 18 preceding patches soon for integration
and I would like to get those in first.
Please do not apply to any tree that will merge into upstream yet,
as it's not ready for prime time.
It only builds (after each patch; sparse and checkpatch clean)
but it has not seen any function testing yet.
There are still some open questions:
* Search victim scsi_device in target_reset_handler just to get a LUN?
(Even if we do, zfcp_fsf_fcp_handler_common() should not print that LUN!)
http://www.spinics.net/lists/linux-scsi/msg111164.html
http://www.spinics.net/lists/linux-scsi/msg111166.html
* Exact rport blocking logic in host_reset_handler.
http://www.spinics.net/lists/linux-scsi/msg111165.html
Steffen Maier (9):
zfcp: drop unsuitable scsi_cmnd usage from SCSI traces for scsi_eh /
TMF
zfcp: decouple TMF response handler from scsi_cmnd
zfcp: split FCP_CMND IU setup between SCSI I/O and TMF again
zfcp: decouple FSF request setup of TMF from scsi_cmnd
zfcp: decouple SCSI setup of TMF from scsi_cmnd
scsi: fc: start decoupling fc_block_scsi_eh from scsi_cmnd
zfcp: use fc_block_rport for TMFs and host reset to decouple from
scsi_cmnd
zfcp: fix waiting for rport(s) unblock in eh_host_reset_handler
zfcp: decouple our scsi_eh callbacks from scsi_cmnd
drivers/s390/scsi/zfcp_dbf.c | 51 ++++++++++++-------
drivers/s390/scsi/zfcp_dbf.h | 26 +++++++---
drivers/s390/scsi/zfcp_ext.h | 12 +++--
drivers/s390/scsi/zfcp_fc.h | 24 ++++++---
drivers/s390/scsi/zfcp_fsf.c | 106 +++++++++++++++++++++++++--------------
drivers/s390/scsi/zfcp_scsi.c | 105 +++++++++++++++++++++++++++++---------
drivers/scsi/scsi_transport_fc.c | 31 ++++++++++--
include/scsi/scsi_transport_fc.h | 1 +
8 files changed, 252 insertions(+), 104 deletions(-)
--
2.11.2
next reply other threads:[~2017-07-25 14:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 14:14 Steffen Maier [this message]
2017-07-25 14:14 ` [RFC 1/9] zfcp: drop unsuitable scsi_cmnd usage from SCSI traces for scsi_eh / TMF Steffen Maier
2017-07-26 5:50 ` Hannes Reinecke
2017-07-25 14:14 ` [RFC 2/9] zfcp: decouple TMF response handler from scsi_cmnd Steffen Maier
2017-07-26 5:52 ` Hannes Reinecke
2017-08-01 16:22 ` Steffen Maier
2017-07-25 14:14 ` [RFC 3/9] zfcp: split FCP_CMND IU setup between SCSI I/O and TMF again Steffen Maier
2017-07-26 5:53 ` Hannes Reinecke
2017-07-25 14:14 ` [RFC 4/9] zfcp: decouple FSF request setup of TMF from scsi_cmnd Steffen Maier
2017-07-26 5:55 ` Hannes Reinecke
2017-08-04 10:33 ` Steffen Maier
2017-07-25 14:14 ` [RFC 5/9] zfcp: decouple SCSI " Steffen Maier
2017-07-26 5:56 ` Hannes Reinecke
2017-07-25 14:14 ` [RFC 6/9] scsi: fc: start decoupling fc_block_scsi_eh " Steffen Maier
2017-07-26 5:58 ` Hannes Reinecke
2017-08-07 17:08 ` Martin K. Petersen
2017-07-25 14:14 ` [RFC 7/9] zfcp: use fc_block_rport for TMFs and host reset to decouple " Steffen Maier
2017-07-26 6:14 ` Hannes Reinecke
2017-07-25 14:14 ` [RFC 8/9] zfcp: fix waiting for rport(s) unblock in eh_host_reset_handler Steffen Maier
2017-07-26 6:16 ` Hannes Reinecke
2017-07-25 14:14 ` [RFC 9/9] zfcp: decouple our scsi_eh callbacks from scsi_cmnd Steffen Maier
2017-07-26 6:16 ` Hannes Reinecke
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=20170725141427.35258-1-maier@linux.vnet.ibm.com \
--to=maier@linux.vnet.ibm.com \
--cc=bblock@linux.vnet.ibm.com \
--cc=hare@suse.de \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.