search for: nbd_rep_server_dir

...+ 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/") => SERVER("dir1/f2"), SERVER("dir1/f3") NBD_OPT_LIST_HIER(&...

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

...s (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 we need some way to mak...

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