From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Nic Bellinger <nab@daterainc.com>,
target-devel@vger.kernel.org, linux-scsi@vger.kernel.org,
Ewan Milne <emilne@redhat.com>
Subject: Re: [PATCH 0/8] tcm_loop updates
Date: Mon, 06 Jul 2015 23:42:33 -0700 [thread overview]
Message-ID: <1436251353.23883.28.camel@haakon3.risingtidesystems.com> (raw)
In-Reply-To: <559B71C6.3030409@suse.de>
On Tue, 2015-07-07 at 08:29 +0200, Hannes Reinecke wrote:
> On 07/07/2015 08:26 AM, Nicholas A. Bellinger wrote:
> > On Tue, 2015-07-07 at 07:50 +0200, Hannes Reinecke wrote:
> >> On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
> >>> On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
> >>>> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
> >
> > <SNIP>
> >
> >>>>> How different do you expect sas, fc, and iscsi transports to be..?
> >>>>>
> >>>>> Do you think this would this be better served by a simple tcm_loop LLD
> >>>>> specific API for different multipath transports..?
> >>>>>
> >>>> Actually, I would split off the various transport functions into
> >>>> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
> >>>> tcm_loop module.
> >>>> We can even make transport classes optional by adding an explicit
> >>>> 'sas.XXX' prefix scanning when creating the device similar to what
> >>>> we do with the 'fc.XXX' prefix already.
> >>>> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
> >>>> which would attach to the respective transport class, and any other
> >>>> WWN (which would be the default) would be getting the standard
> >>>> emulation without any transport class attached.
> >>>
> >>> I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
> >>> transport pieces, or wait until you've done a large split based on
> >>> transport class types.
> >>>
> >>> It's really your call how the initial merge should look.
> >>>
> >> Probably leave out the transport class stuff for now; I kinda like
> >> the idea of having all types of transport classes available for
> >> tcm_loop.
> >> But this is actually not related to the rest of the patchset, so
> >> you can skip those for the time being.
> >>
> >
> > Just to confirm, applying patch #3-#6, and #8 to for-next now.
> >
> > Skipping #7 for the moment, given host side expectations short of being
> > configurable as noted by HCH.
> >
> Precisely. Thank you.
>
Whoops, forgot that logic for #6 was already applied to v4.2-rc1, and
HCH had some objections to patch #8.
Also, #5 does depend on the sas transport class support.
So just applying #3-#4 for now..
prev parent reply other threads:[~2015-07-07 6:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
2015-06-18 9:43 ` [PATCH 1/8] tcm_loop: Hook into SAS transport class Hannes Reinecke
2015-06-18 9:43 ` [PATCH 2/8] tcm_loop: Add SAS transport topology Hannes Reinecke
2015-06-18 9:43 ` [PATCH 3/8] tcm_loop: Remove SAS vestigies Hannes Reinecke
2015-06-18 9:43 ` [PATCH 4/8] tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA Hannes Reinecke
2015-06-18 9:43 ` [PATCH 5/8] tcm_loop: Rescan SCSI target on transport online Hannes Reinecke
2015-06-18 9:43 ` [PATCH 6/8] target: Issue Power-On/Reset UA upon LUN instantiation Hannes Reinecke
2015-06-18 9:43 ` [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby Hannes Reinecke
2015-06-18 11:40 ` Chris Boot
2015-06-18 14:32 ` Hannes Reinecke
2015-06-19 6:49 ` Christoph Hellwig
2015-06-19 7:07 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs Hannes Reinecke
2015-06-19 6:51 ` Christoph Hellwig
2015-06-19 7:05 ` Hannes Reinecke
2015-06-19 6:48 ` [PATCH 0/8] tcm_loop updates Christoph Hellwig
2015-06-19 7:13 ` Hannes Reinecke
2015-06-23 8:29 ` Nicholas A. Bellinger
2015-06-23 9:05 ` Hannes Reinecke
2015-07-07 0:25 ` Nicholas A. Bellinger
2015-07-07 5:50 ` Hannes Reinecke
2015-07-07 6:26 ` Nicholas A. Bellinger
2015-07-07 6:29 ` Hannes Reinecke
2015-07-07 6:42 ` Nicholas A. Bellinger [this message]
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=1436251353.23883.28.camel@haakon3.risingtidesystems.com \
--to=nab@linux-iscsi.org \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@daterainc.com \
--cc=target-devel@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.