similar to: [PATCH nbdkit] server: Deprecate the -e/--exportname parameter.

While we are unlikely to change our decision that -e should not control our response to NBD_OPT_LIST (because we intend to add a new callback .extents_list for that), it turns out that it is a lot easier to write: nbdkit -U - -e foo info --run 'nbdsh -u "$uri" -c "print(h.pread(3, 0))"' than it is to write the equivalent: nbdkit -U - info --run 'nbdsh -u

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

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

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

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

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'

To allow filters to modify the export name as it passes through the layers this commit makes several changes: The filter .open callback now takes an extra parameter, the export name. This is always non-NULL (for oldstyle it is ""). This string has a short lifetime and filters that need to hang on to it must take a copy. The filter must pass the exportname parameter down to the next

On 9/15/19 9:55 AM, Richard W.M. Jones wrote: > 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 >

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

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

On 9/17/19 2:42 AM, Richard W.M. Jones wrote: > On Mon, Sep 16, 2019 at 10:33:18AM -0500, Eric Blake wrote: >> Is it worth noting that the NBD protocol imposes a 4k limit on the >> export name, which would limit things to about a 3k disk image when >> using base64? (It looks like nbdkit does not currently enforce that >> limit -- maybe it should, but as a separate patch

On 9/10/19 6:20 AM, Richard W.M. Jones wrote: > This allows plugins (or filters) to read the export name which was > passed to the server from the client. > > UNFINISHED: > > - Needs tests > --- > TODO | 8 ++++++ > docs/nbdkit-plugin.pod | 39 ++++++++++++++++++++++++++++ > server/connections.c | 1 +

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

On Mon, Sep 16, 2019 at 10:33:18AM -0500, Eric Blake wrote: > Is it worth noting that the NBD protocol imposes a 4k limit on the > export name, which would limit things to about a 3k disk image when > using base64? (It looks like nbdkit does not currently enforce that > limit -- maybe it should, but as a separate patch -- but even if we > don't change that, you're still

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] -

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

On Thu, Aug 06, 2020 at 09:23:48PM -0500, Eric Blake wrote: > Add a new filter to make it easier to add exports to a plugin that > does advertise them, to avoid advertising where a plugin's list might does *not* advertise them(?) > be an information leak, and to alter which export name is used in > place of "". > > I would love to be able to have a strict mode

Up to nbdkit 1.22, we never advertised large export lists, so a client had no real reason to give more than 32 NBD_OPT_ commands before finally selecting 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

This happened on s390 in Koji, once. The key lines from the log are: + start_t=0 nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying + end_t=1 Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0) was called twice by the retry filter). But in the bash script, time (as measured by $SECONDS) advanced