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 17:25:03 -0700 [thread overview]
Message-ID: <1436228703.5138.2.camel@haakon3.risingtidesystems.com> (raw)
In-Reply-To: <55892164.6020907@suse.de>
On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
> > On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
> >> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
> >>> What's the benefit of the SAS transport class writeout? I honestly
> >>> always saw tcm_loop as a simple loopback driver, with the different
> >>> transport IDs in the PR code as a gimmick. Note that vhost and
> >>> xen-blkback copies that style and I did plan to consolidate it
> >>> in common code.
> >>>
> >> The benefit is that tcm_loop will show up in the system as a 'real'
> >> SAS hba; long-term goal is to simulate SAS multipathing here.
> >> I was even planning on adding simlated FC infrastructure, too;
> >> with that we could simulate FC multipathing, too, and our QA would
> >> be _so_ happy...
> >>
> >
> > Sounds like a reasonable use-case to support for loopback testing.
> >
> >> Again, these patches are mainly a collection of patches I've done to
> >> test various scenarios, in the hope others might find them useful,
> >> too. So I can easily hold off these patches until you've posted your
> >> rework.
> >>
> >
> > 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.
--nab
next prev parent reply other threads:[~2015-07-07 0:25 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 [this message]
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
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=1436228703.5138.2.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.