* targetcli and nvmetcli
@ 2017-01-06 19:05 Andy Grover
2017-01-06 20:34 ` Freyensee, James P
2017-01-08 9:58 ` Christoph Hellwig
0 siblings, 2 replies; 3+ messages in thread
From: Andy Grover @ 2017-01-06 19:05 UTC (permalink / raw)
Hi James and Christoph,
Have you considered integrating nvmetcli with targetcli?
I see there being reasons why it was developed as a standalone, but I'm
not sure how many of these still apply.
Especially given their shared source history, combining them at the cli
level, or even the lib level, would be straightforward, and could give
users a unified tool for managing both types of targets.
What do you think?
Thanks -- Regards -- Andy
^ permalink raw reply [flat|nested] 3+ messages in thread
* targetcli and nvmetcli
2017-01-06 19:05 targetcli and nvmetcli Andy Grover
@ 2017-01-06 20:34 ` Freyensee, James P
2017-01-08 9:58 ` Christoph Hellwig
1 sibling, 0 replies; 3+ messages in thread
From: Freyensee, James P @ 2017-01-06 20:34 UTC (permalink / raw)
On Fri, 2017-01-06@11:05 -0800, Andy Grover wrote:
> Hi James and Christoph,
>
> Have you considered integrating nvmetcli with targetcli?
>
> I see there being reasons why it was developed as a standalone, but I'm?
> not sure how many of these still apply.
>
> Especially given their shared source history, combining them at the cli?
> level, or even the lib level, would be straightforward, and could give?
> users a unified tool for managing both types of targets.
>
> What do you think?
I donno, in my opinion, it seems from support/maintenance to philosophy
difference it would be confusing and difficult to combine the two. ?NVMe is a
new storage protocol with its own terminology (ex namespaces vs LUNS), defined
in its own standard, written by its own standard body that reserves the right
to not necessarily follow what iSCSI does (though there are a few borrowed
concepts like IQNs), and is supported by its own Linux email list.
Christoph has done design work on both the NVMe Target and LIO so he could give
a more intelligent technical answer than me.
Jay
>
> Thanks -- Regards -- Andy
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 3+ messages in thread
* targetcli and nvmetcli
2017-01-06 19:05 targetcli and nvmetcli Andy Grover
2017-01-06 20:34 ` Freyensee, James P
@ 2017-01-08 9:58 ` Christoph Hellwig
1 sibling, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2017-01-08 9:58 UTC (permalink / raw)
On Fri, Jan 06, 2017@11:05:01AM -0800, Andy Grover wrote:
> Hi James and Christoph,
>
> Have you considered integrating nvmetcli with targetcli?
We looked into all the options earlier and decided against it.
The NVMe object are a lot more standardized than those for the SCSI
transports, and both the kernel nvme target condigfs code, and thus
nvmetcli take advantage of that to provide a more coherent user interface.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-08 9:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-06 19:05 targetcli and nvmetcli Andy Grover
2017-01-06 20:34 ` Freyensee, James P
2017-01-08 9:58 ` Christoph Hellwig
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.