search for: nbd_opt_list_hier

...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: "f1", "dir1/f2", "dir1/f3", "dir2/f4". But what if the protocol added NBD_OPT_LIST_HIER which took a starting point argument, and new replies NBD_REP_SERVER_DIR and NBD_REP_ERR_NOTDIR, such that we could then have: NBD_OPT_LIST_HIER("") => SERVER("f1"), SERVER_DIR("dir1/"), SERVER_DIR("dir2/") NBD_OPT_LIST_HIER("dir1/") => SE...

Hi Eric, Nir. $SUBJECT - it's complicated! Imagine a scenario where we have extended the file plugin so you can point it at a directory and it will use the client-supplied export name to select a file to serve. Also we have extended the tar filter so that you can map tar file components into export names. You may be able to see where this is going ... Now we point the file plugin at a

...product of export names (for each export offered by the plugin, the filter then determines a sublist of items from that plugin content), which implies multiple .plugin opens (in this mode, we probably DO want to pursue my proposal in an earlier thread about enhancing the NBD protocol to add an NBD_OPT_LIST_HIER and NBD_REP_SERVER_DIR to allow hierarchical traversal rather than flat listing of every possible export at once). For 1), the interface for the filter is like any other interface - provide a hook for filters to call, along with a next_ops to defer into the plugin. But for 2) I'm thinking...

...ent a full .list_exports; doing that with NBD_OPT_LIST is likely prohibitive (it's likely the disk contains LOTS of files), and would require that we can do next_ops->pread prior to the client reaching our .open. For the former issue, it would be better if the NBD protocol adds a new option NBD_OPT_LIST_HIER that has replies that differentiate between containers and leaves, and only lists elements within a container supplied as an argument. For the latter, we already know we want to tweak filters to be able to open a plugin independently of a client's connection. And for now we punt, and leave th...

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

Applies on top of my pending series for the exportname filter, addressing one of the todo's in that cover letter. Eric Blake (2): filters: Add .export_description wrappers ext2: Supply .list_exports and .default_export filters/ext2/nbdkit-ext2-filter.pod | 3 +- tests/Makefile.am | 16 +++- filters/ext2/ext2.c | 125 +++++++++++++++++++---------

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update