search for: nbd_opt_list

This is a subset of my v2 posting, but limited to just the NBD_OPT_LIST handling. The biggest change since v2 is the addition of added unit testing in all four language bindings (C, python, ocaml, golang). The tests require nbdkit built from git on PATH, and may not be entirely idiomatic, but I at least validated that they catch issues (for example, adding an exit sta...

This continues the changes for adding NBD_OPT_LIST support. Now, instead of libnbd malloc'ing storage itself, the user passes a callback that can handle name/description pairs however it likes, and we get rid of the artificial cap at 10000 exports. However, the user will probably end up malloc'ing a list themselves, as we can't call n...

This continues the changes for adding NBD_OPT_LIST support. Now, instead of libnbd malloc'ing storage itself, the user passes a callback that can handle name/description pairs however it likes, and we get rid of the artificial cap at 10000 exports. However, the user will probably end up malloc'ing a list themselves, as we can't call n...

...te_machine); > Group ("OPT_SET_META_CONTEXT", newstyle_opt_set_meta_context_state_machine); > Group ("OPT_GO", newstyle_opt_go_state_machine); > @@ -341,6 +342,44 @@ and newstyle_opt_starttls_state_machine = [ > }; > ] > > +(* Fixed newstyle NBD_OPT_LIST option. *) > +and newstyle_opt_list_state_machine = [ > + State { > + default_state with > + name = "START"; > + comment = "Start listing exports if in list mode."; > + external_events = []; > + }; > + > + State { > + default_state...

...ing an export or quitting, and we were justified in dropping indecisive chatty clients as being a waste of server resources. But now that we support .list_exports, it is reasonable for a client (such as 'qemu-nbd --list' or 'nbdinfo --list') to want to call NBD_OPT_INFO and several NBD_OPT_LIST_META_CONTEXT commands for every export returned in NBD_OPT_LIST. We still want to avoid clients that can tie us up in eternal handshaking, so let's reject a second call to NBD_OPT_LIST; but once the first call is made, the client now has a chance to get info on everything listed. Signed-off-b...

...trary limits (what escape character to use? what is the max length?) Also changing the NBD protocol is not under consideration. I think we need to consider these aspects separately: (a) How filters and plugins get the client exportname. (b) How filters and plugins respond when the client issues NBD_OPT_LIST. (c) How the server, filters and plugins respond to NBD_OPT_INFO. (a) Client exportname --------------------- The client sends the export name of the export it wants to access with NBD_OPT_EXPORT_NAME or the newer NBD_OPT_GO. This is an opaque string (not a filename, pathname etc). Currently...

...quot;, newstyle_opt_structured_reply_state_machine); Group ("OPT_SET_META_CONTEXT", newstyle_opt_set_meta_context_state_machine); Group ("OPT_GO", newstyle_opt_go_state_machine); @@ -341,6 +342,44 @@ and newstyle_opt_starttls_state_machine = [ }; ] +(* Fixed newstyle NBD_OPT_LIST option. *) +and newstyle_opt_list_state_machine = [ + State { + default_state with + name = "START"; + comment = "Start listing exports if in list mode."; + external_events = []; + }; + + State { + default_state with + name = "SEND"; + comment =...

Proposal for new APIs to list exports. The general shape of the API can probably best be seen from the examples/list-exports.c example. Rich.

On Thu, Aug 06, 2020 at 09:23:46PM -0500, Eric Blake wrote: > + if (!filename == !directory) { A bit tricksy. In plugins/nbd/nbd.c I used: int c = !!sockname + !!hostname + !!uri + (command.size > 0) + (socket_fd >= 0) + !!raw_cid; /* Check the user passed exactly one connection parameter. */ if (c > 1) { nbdkit_error ("cannot mix Unix ‘socket’, TCP

...tiating for new state api: Permit several existing API in Negotiating state api: Add nbd_set_opt_mode api: Add nbd_opt_abort and nbd_aio_opt_abort api: Add nbd_opt_go and nbd_aio_opt_go examples: Update list-exports to demonstrate nbd_opt_go info: Simplify by using nbd_opt_go api: Add nbd_opt_list api: Add nbd_aio_opt_list wip: api: Give aio_opt_go a completion callback wip: api: add nbd_opt_info, nbd_aio_opt_info docs/libnbd.pod | 42 +- lib/internal.h | 45 +- lib/nbd-protocol.h | 10 +- gene...

Updated proposal, taking into account the default export. Instead of adding a second call, I made a couple of changes to list_exports: (1) If the plugin has a concept of a default export, it should add it as the first element in the exports list. (2) There is a new default_only flag which tells the plugin that the client is trying to request the name of the default export, so the

...onsidered because they are too risky, and run into arbitrary > limits (what escape character to use? what is the max length?) Also > changing the NBD protocol is not under consideration. Not directly, but maybe it is worth adding optional support to the NBD protocol to make it possible for NBD_OPT_LIST to support a hierarchical return. That is, pointing the file plugin to serve directory=base containing the following layout: base + f1 + dir1 + f2 + f3 + dir2 + f4 the current semantics of NBD_OPT_LIST only lend themselves to returning 4 NBD_REP_SERVER replies in a row: &quot...

...e connection, call C<nbdkit_error> with an error message and return C<-1>. +=head2 C<.list_exports> + + int list_exports (int readonly, struct nbdkit_exports *exports); + +This optional callback is called if the client tries to list the +exports served by the plugin (using C<NBD_OPT_LIST>). If the plugin +does not supply this callback then a single export called C<""> is +returned. The NBD protocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L&lt...

...,9 @@ nbd_unlocked_aio_opt_list (struct nbd_handle *h, nbd_list_callback *list, assert (CALLBACK_IS_NULL (h->opt_cb.fn.list)); h->opt_cb.fn.list = *list; + SET_CALLBACK_TO_NULL (*list); h->opt_cb.completion = *complete; + SET_CALLBACK_TO_NULL (*complete); h->opt_current = NBD_OPT_LIST; if (nbd_internal_run (h, cmd_issue) == -1) debug (h, "option queued, ignoring state machine failure"); diff --git a/lib/rw.c b/lib/rw.c index 9f2909b..4b8eeaf 100644 --- a/lib/rw.c +++ b/lib/rw.c @@ -72,6 +72,7 @@ nbd_unlocked_pread_structured (struct nbd_handle *h, void *buf,...

As promised in my earlier thread on libnbd completion callback question. Eric Blake (2): generator: Refactor handling of closures in unlocked functions generator: Free closures on failure docs/libnbd.pod | 2 +- generator/C.ml | 48 +++++++++++------ generator/C.mli | 1 + lib/debug.c | 7 +-- lib/opt.c | 31 ++++++-----

...t; with an error message and return C<-1>. +=head2 C<.list_exports> + + int list_exports (int readonly, int default_only, + struct nbdkit_exports *exports); + +This optional callback is called if the client tries to list the +exports served by the plugin (using C<NBD_OPT_LIST>). If the plugin +does not supply this callback then a single export called C<""> is +returned. The NBD protocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L&lt...

On 08/06/2018 09:31 AM, Nir Soffer wrote: > Eric, can you point us to the part of the spec allowing ignoring the export > name sent by the client? Nothing in the NBD spec requires the server to reject unknown export names. So nbdkit never rejects export names (which means it behaves as if all names work, regardless of whether or not it was the name it was configured with, since it

...> >+ NEWSTYLE.OPT_LIST.START: > >+ if (!h->list_exports) { > >+ SET_NEXT_STATE (%^OPT_STRUCTURED_REPLY.START); > >+ return 0; > >+ } > >+ > >+ h->sbuf.option.version = htobe64 (NBD_NEW_VERSION); > >+ h->sbuf.option.option = htobe32 (NBD_OPT_LIST); > >+ h->sbuf.option.optlen = 0; > >+ h->wbuf = &h->sbuf; > >+ h->wlen = sizeof (h->sbuf.option); > >+ SET_NEXT_STATE (%SEND); > >+ return 0; > > Is it worth enhancing the code to add another list mode where we can > also query NBD_OP...

qemu is about to add 'qemu-nbd --list', which exercises NBD_OPT_LIST and NBD_OPT_INFO to give the user as much detail as possible about an export without actually connecting to it. For that to display more than the export name when nbdkit is the server, we need to implement NBD_OPT_INFO. Thankfully, the NBD spec intentionally made the command very similar to NBD_O...

...gt; with an error message and return C<-1>. +=head2 C<.list_exports> + + int list_exports (int readonly, int default_only, + struct nbdkit_exports *exports); + +This optional callback is called if the client tries to list the +exports served by the plugin (using C<NBD_OPT_LIST>). If the plugin +does not supply this callback then a single export called C<""> is +returned. The NBD protocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L&lt...