similar to: [nbdkit PATCH] server: Reinstate limited use of -e/-exportname.

This parameter provided a name for the "default export" -- ie. the one and only export returned to the client by NBD_OPT_LIST. But nbdkit traditionally didn't care what export name the client requested. Since 1.16 plugins have been able to serve different content per export name (and return errors for unknown exports), but the -e option didn't reflect that and only created

On 7/21/20 10:10 AM, Richard W.M. Jones wrote: > This parameter provided a name for the "default export" -- ie. the one > and only export returned to the client by NBD_OPT_LIST. But nbdkit > traditionally didn't care what export name the client requested. > Since 1.16 plugins have been able to serve different content per > export name (and return errors for unknown

Since the v1 series (0/4, at [1]), I've applied patches 1 and 2, rewritten patch 3 [Forbid NUL in export and context names] into patch 4 here, patch 4 there turned into patch 6 here, and everything else here is new. [1]https://www.redhat.com/archives/libguestfs/2019-September/msg00180.html I don't know if there is a handy reusable function for checking whether a string contains valid

On Wed, Jul 22, 2020 at 12:58:07PM -0500, Eric Blake wrote: [...] This is fine, but there is a minor thing: > docs/nbdkit-protocol.pod | 2 +- In the original patch I removed this hunk from nbdkit-protocol.pod: @@ -5,7 +5,7 @@ nbdkit - which parts of the NBD protocol nbdkit supports =head1 SYNOPSIS nbdkit [-n|--newstyle] [--mask-handshake MASK] [--no-sr] [-o|--oldstyle] -

Fixes the fact that clients could not request the maximum string length except with NBD_OPT_EXPORT_LEN. Updates the testsuite to match. Signed-off-by: Eric Blake <eblake@redhat.com> --- server/protocol-handshake-newstyle.c | 12 +++++++----- tests/test-long-name.sh | 10 ++++------ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git

For mainly historical reasons we tended to use int to store boolean values. However using bool is probably safer in some corner cases (eg. ?v == true? can fail badly if v is an int, but works for bool). bool was added in C99 so let's use it. --- server/internal.h | 16 +++++------ server/connections.c | 28 +++++++++--------- server/crypto.c | 4 +-- server/main.c | 67

Now that kernels support vsock loopback, we have no reason to forbid --vsock with --run. Signed-off-by: Eric Blake <eblake@redhat.com> --- I'm hoping to commit something like this, but right now, the testsuite is failing more times than it succeeds, with: + port=1082294412 + nbdkit --vsock --port 1082294412 memory 1M --run 'sleep 1; nbdsh -u "$uri" -c

On Tue, Jul 21, 2020 at 07:51:29PM -0500, Eric Blake wrote: > On 7/21/20 12:46 PM, Eric Blake wrote: > > >>(2) The --run option no longer sets $exportname (to -e) nor puts the > >>     export name into the $uri.  However this was always the wrong > >>     thing to do since export names are per connection, not per server. > >>     Existing --run scripts

On 7/21/20 12:46 PM, Eric Blake wrote: >> (2) The --run option no longer sets $exportname (to -e) nor puts the >>      export name into the $uri.  However this was always the wrong >>      thing to do since export names are per connection, not per server. >>      Existing --run scripts will see $exportname expand to "" which is >>      most likely what they

On 7/22/20 4:02 AM, Richard W.M. Jones wrote: >> The more I think about it, the more I disagree with disabling this. >> Or, put another way, I think that the _only_ time -e makes sense is >> _when_ you are using --run. Consider: >> >> nbdkit -U - -e foo info --run 'nbdsh -u $uri -c "print(h.pread(3, 0))"' >> nbdkit -U - -e bar info --run

Similar to --no-sr, it can be handy for testing a client implementation to have a server that can easily be forced into older behaviors, without having to recompile a one-off hack into a server or dig up an older server binary that lacked a newer feature. To see the patch in action, try things like: $ ./nbdkit -U - -fv --mask-handshake=0 null \ --run 'qemu-nbd --list -k $unixsocket'

When we added support for .extents, we had nbdkit unconditionally support structured replies if the client requests them, and the plugin's .can_extents has no impact on what the server advertises. However, while the plugin API doesn't care whether the client requested SR, there are still integration situations where not advertising SR can be useful (such as comparison on what a client does

See commit 2a29634aa0589037b5625032097a3a2f7b1d5c7d and https://www.redhat.com/archives/libguestfs/2019-September/msg00366.html --- configure.ac | 4 +- plugins/data/nbdkit-data-plugin.pod | 2 +- plugins/{reflection => info}/Makefile.am | 20 ++++----- .../{reflection/reflection.c => info/info.c} | 42 +++++++++----------

The NBD spec says that if a client requests SET_META_CONTEXT for exportA, but later requests NBD_OPT_GO/EXPORT_NAME for exportB, then the server should reject NBD_CMD_BLOCK_STATUS requests (that is, the context returned for exportA need not apply to exportB). When we originally added base:allocation, our argument was that we always ignore export names, so it was easier to just treat any two

When “nbdkit ... --run 'nbdinfo ...' > out” is expected to fail, we cannot be sure of the content of the "out" file. In particular nbdinfo produces its output incrementally, so in JSON mode there's usually a stray "{" in the output, and in non-JSON mode it usually prints the "protocol: " line. Thus it's not correct to test for the output file

On 7/21/20 7:46 AM, Richard W.M. Jones wrote: > 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

The source for the easter egg example is not included, but it is: org 0x7c00 ; clear screen mov ah,0 mov al,3 int 0x10 ; print string mov ah,0x13 mov bl,0xa mov al,1 mov cx,len mov dh,0 mov dl,0 mov bp,hello int 0x10 hlt hello: db "*** Hello from nbdkit! ***",0xd,0xa

The NBD spec says that if a client requests SET_META_CONTEXT for exportA, but later requests NBD_OPT_GO/EXPORT_NAME for exportB, then the server should reject NBD_CMD_BLOCK_STATUS requests (that is, the context returned for exportA need not apply to exportB). When we originally added base:allocation, our argument was that we always ignore export names, so it was easier to just treat any two

This creates filesystems on demand. A client simply connects with a desired export name and a new export is created. The export is persistent (until deleted by the server admin), and clients may disconnect and reconnect. In some respects this is similar to the nbdkit-tmpdisk-plugin, or nbdkit-file-plugin with the dir= option. --- plugins/ondemand/nbdkit-ondemand-plugin.pod | 190 ++++++

On Wed, Jul 22, 2020 at 06:12:30AM -0500, Eric Blake wrote: > On 7/22/20 4:02 AM, Richard W.M. Jones wrote: > >Perhaps we should have a rule something like this: > > > > - plugins should serve default content on the "" export > > > > - unless they implement .list_exports, in which case the > > first export returned is the default export >