linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* nvmet and stable API
@ 2020-03-24 18:15 Tony Asleson
  2020-03-25  6:58 ` Sagi Grimberg
  0 siblings, 1 reply; 4+ messages in thread
From: Tony Asleson @ 2020-03-24 18:15 UTC (permalink / raw)
  To: linux-nvme

With the existing functionality of nvmetcli in that you can
save/restore/clear/ls and use interactively seems to indicate that if
you want to programmaticlly change the state of targets that you need to
use the python code that is available in nvmet which is used by the CLI.
 Is this a correct assumption, that nvmet is an API for external python
programs to use?

The block tests in https://github.com/osandov/blktests.git seem to
indicate that going straight to configfs is the API?

Thanks,
Tony


_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: nvmet and stable API
  2020-03-24 18:15 nvmet and stable API Tony Asleson
@ 2020-03-25  6:58 ` Sagi Grimberg
  2020-04-01 16:34   ` Tony Asleson
  0 siblings, 1 reply; 4+ messages in thread
From: Sagi Grimberg @ 2020-03-25  6:58 UTC (permalink / raw)
  To: tasleson, linux-nvme


> With the existing functionality of nvmetcli in that you can
> save/restore/clear/ls and use interactively seems to indicate that if
> you want to programmaticlly change the state of targets that you need to
> use the python code that is available in nvmet which is used by the CLI.

nvmetcli needs to be backward compatible with kernels lacking
functionality. Anywhere this is not the case, its a bug and we need
to fix it.

>   Is this a correct assumption, that nvmet is an API for external python
> programs to use?

We don't have an API for python. I sort of assumed that this will
be contributed by the people that want/need it.

> The block tests in https://github.com/osandov/blktests.git seem to
> indicate that going straight to configfs is the API?

That's for dependency minimization.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: nvmet and stable API
  2020-03-25  6:58 ` Sagi Grimberg
@ 2020-04-01 16:34   ` Tony Asleson
  2020-04-03  6:53     ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Tony Asleson @ 2020-04-01 16:34 UTC (permalink / raw)
  To: Sagi Grimberg, linux-nvme

On 3/25/20 1:58 AM, Sagi Grimberg wrote:

> We don't have an API for python. I sort of assumed that this will
> be contributed by the people that want/need it.

Maybe, I'm interpreting this statement incorrectly, if so please
clarify.  I'm reading this as write what you need for whatever language
to configfs.  This works and it's not difficult to do, but what to do
for persistence?

Try to write compatible JSON output across code bases and supported
kernel features?  Have everyone fork & exec "nvmetcli save"?  Write out
your own file and document not to use incompatible stacks?

Additionally, none of this addresses a potential race condition between
two or more processes with different implementations making concurrent
changes to configfs and getting the configuration saved with no lost
changes.

Suggestions?

Thanks,
Tony



_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: nvmet and stable API
  2020-04-01 16:34   ` Tony Asleson
@ 2020-04-03  6:53     ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2020-04-03  6:53 UTC (permalink / raw)
  To: Tony Asleson; +Cc: Sagi Grimberg, linux-nvme

On Wed, Apr 01, 2020 at 11:34:34AM -0500, Tony Asleson wrote:
> On 3/25/20 1:58 AM, Sagi Grimberg wrote:
> 
> > We don't have an API for python. I sort of assumed that this will
> > be contributed by the people that want/need it.
> 
> Maybe, I'm interpreting this statement incorrectly, if so please
> clarify.  I'm reading this as write what you need for whatever language
> to configfs.  This works and it's not difficult to do, but what to do
> for persistence?
> 
> Try to write compatible JSON output across code bases and supported
> kernel features?  Have everyone fork & exec "nvmetcli save"?  Write out
> your own file and document not to use incompatible stacks?
> 
> Additionally, none of this addresses a potential race condition between
> two or more processes with different implementations making concurrent
> changes to configfs and getting the configuration saved with no lost
> changes.
> 
> Suggestions?

What would be your preference?  You seems to be the main interested
party that wants another interface than nvmetcli for production usage
(all other uses is just tests), so maybe you an propose something
that works for you?

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-04-03  6:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-24 18:15 nvmet and stable API Tony Asleson
2020-03-25  6:58 ` Sagi Grimberg
2020-04-01 16:34   ` Tony Asleson
2020-04-03  6:53     ` Christoph Hellwig

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).