search for: nbd_info_name

The NBD spec says that additional information in response to NBD_OPT_GO or NBD_OPT_INFO, such as NBD_INFO_NAME, is optional, but also recommends that if a client hints about wanting a particular piece of information, that it is better for the server to reply to those known hints. This is also the the only way for a client to learn the canonical name that is used when connecting to the default export name....

...ur API in stone. First, .list_exports needs to know if it is pre- or post-TLS, as that may affect which names are exported. Next, overloading .list_exports to do both NBD_OPT_LIST and mapping "" to a canonical name is proving to be awkward; the canonical mapping is only needed during an NBD_INFO_NAME response to NBD_OPT_GO, and making .open try to grab the entire .list_exports list just to use only the first entry (even if the plugin optimized based on the bool to only provide one entry) is awkward, compared to just having a dedicated function. Finally, as long as we are going to support NBD_I...

....list_exports > needs to know if it is pre- or post-TLS, as that may affect which > names are exported. Next, overloading .list_exports to do both > NBD_OPT_LIST and mapping "" to a canonical name is proving to be > awkward; the canonical mapping is only needed during an > NBD_INFO_NAME response to NBD_OPT_GO, and making .open try to > grab the entire .list_exports list just to use only the first > entry (even if the plugin optimized based on the bool to only > provide one entry) is awkward, compared to just having a > dedicated function. Finally, as long as we are go...

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map "" into a canonical name prior to .open (as the plugin is easier to...

...gt;needs to know if it is pre- or post-TLS, as that may affect which > >names are exported. Next, overloading .list_exports to do both > >NBD_OPT_LIST and mapping "" to a canonical name is proving to be > >awkward; the canonical mapping is only needed during an > >NBD_INFO_NAME response to NBD_OPT_GO, and making .open try to > >grab the entire .list_exports list just to use only the first > >entry (even if the plugin optimized based on the bool to only > >provide one entry) is awkward, compared to just having a > >dedicated function. Finally, as l...

...ntern (nbdkit_realpath (value), true)) == NULL) return -1; } Also, more than just the file plugin shares the pattern of copying off a config name where we could simplify or eliminate .unload by interning the string. Eric Blake (5): api: Add .default_export server: Respond to NBD_INFO_NAME request api: Add nbdkit_string_intern helper file: Utilize nbdkit_string_intern sh, eval: Implement .default_export docs/nbdkit-filter.pod | 37 ++++++--- docs/nbdkit-plugin.pod | 66 +++++++++++++++- plugins/eval/nbdkit-eval-plugin.pod | 2 + plugins/sh/nbd...

...E (1 << 0) +#define NBD_FLAG_NO_ZEROES (1 << 1) /* Per-export flags. */ #define NBD_FLAG_HAS_FLAGS (1 << 0) @@ -143,6 +143,9 @@ struct nbd_fixed_new_option_reply { #define NBD_REP_ERR_TOO_BIG NBD_REP_ERR (9) #define NBD_INFO_EXPORT 0 +#define NBD_INFO_NAME 1 +#define NBD_INFO_DESCRIPTION 2 +#define NBD_INFO_BLOCK_SIZE 3 /* NBD_INFO_EXPORT reply (follows fixed_new_option_reply). */ struct nbd_fixed_new_option_reply_info_export { -- 2.21.0

...E (1 << 0) +#define NBD_FLAG_NO_ZEROES (1 << 1) /* Per-export flags. */ #define NBD_FLAG_HAS_FLAGS (1 << 0) @@ -140,6 +143,9 @@ struct nbd_fixed_new_option_reply { #define NBD_REP_ERR_TOO_BIG NBD_REP_ERR (9) #define NBD_INFO_EXPORT 0 +#define NBD_INFO_NAME 1 +#define NBD_INFO_DESCRIPTION 2 +#define NBD_INFO_BLOCK_SIZE 3 /* NBD_INFO_EXPORT reply (follows fixed_new_option_reply). */ struct nbd_fixed_new_option_reply_info_export { @@ -160,15 +166,6 @@ struct nbd_block_descriptor { uint32_t status_flags; /* block type (hole etc) */...

...the largest file in the directory for "") - the tar filter should consider an exportname mode - figure out how to let filters open the plugin without a current connection into the filter Eric Blake (8): api: Add .default_export api: Add nbdkit_add_default_export server: Respond to NBD_INFO_NAME request api: Add nbdkit_str[n]dup_intern helper sh, eval: Implement .default_export api: Alter .list_exports api: Add .export_description exportname: New filter docs/nbdkit-filter.pod | 56 ++- docs/nbdkit-plugin.pod | 123 ++++++- docs/nbd...

More nbd-protocol.h improvements Eric Blake (2): common/protocol: Switch nbdmagic to uint64_t common/protocol: Declare additional constants common/protocol/nbd-protocol.h | 16 ++++++++++------ server/protocol-handshake-newstyle.c | 2 +- server/protocol-handshake-oldstyle.c | 2 +- plugins/nbd/nbd-standalone.c | 2 +- tests/test-layers.c | 2 +- 5 files

...en upstream/downstream patch [down] : patch is downstream-only The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively 001/14:[0059] [FC] 'api: Add .default_export' 002/14:[down] 'api: Add nbdkit_use_default_export' 003/14:[0059] [FC] 'server: Respond to NBD_INFO_NAME request' 004/14:[0021] [FC] 'sh, eval: Implement .default_export' 005/14:[0036] [FC] 'api: Alter .list_exports' 006/14:[0032] [FC] 'api: Add .export_description' 007/14:[0015] [FC] 'exportname: New filter' 008/14:[0049] [FC] 'filters: Add .export_description...

...ust be unique. C<description> is an @@ -725,7 +727,10 @@ default export C<"">, where the plugin provides a UTF-8 string between connection continues with the empty name; if the plugin returns a valid string, nbdkit returns that name to clients that support it (see the C<NBD_INFO_NAME> response to C<NBD_OPT_GO>), and behaves as if the -client had passed that string instead of an empty name. +client had passed that string instead of an empty name. Similarly, if +the plugin does not supply a C<.list_exports> callback, the result of +this callback determines what ex...

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

...it - * Copyright (C) 2013-2019 Red Hat Inc. + * Copyright (C) 2013-2020 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -146,6 +146,7 @@ struct nbd_fixed_new_option_reply { #define NBD_INFO_NAME 1 #define NBD_INFO_DESCRIPTION 2 #define NBD_INFO_BLOCK_SIZE 3 +#define NBD_INFO_INIT_STATE 4 /* NBD_INFO_EXPORT reply (follows fixed_new_option_reply). */ struct nbd_fixed_new_option_reply_info_export { @@ -154,6 +155,16 @@ struct nbd_fixed_new_option_reply_info_export { uint16_t...

...;description> is an > @@ -725,7 +727,10 @@ default export C<"">, where the plugin provides a UTF-8 string between > connection continues with the empty name; if the plugin returns a > valid string, nbdkit returns that name to clients that support it (see > the C<NBD_INFO_NAME> response to C<NBD_OPT_GO>), and behaves as if the > -client had passed that string instead of an empty name. > +client had passed that string instead of an empty name. Similarly, if > +the plugin does not supply a C<.list_exports> callback, the result of > +this callbac...

...s optional callback is called if the client tries to connect to +the default export C<"">. If the plugin does not supply this callback, +the connection continues with the empty name; if the plugin returns +a string, nbdkit returns that name to clients that support it (see +the C<NBD_INFO_NAME> response to C<NBD_OPT_GO>), and behaves as if +the client had passed that string instead of an empty name. Similarly, +if the plugin does not supply a C<.list_exports> callback, the result +of this callback determines what export name to advertise to a client +requesting an export...

Well, I'm not quite done (I still want to get nbdinfo to work on a single nbd connection for all cases when reading the heads of the file is not required), but I'm happy with patches 1-11, and 12-13 show where I'm headed for getting NBD_OPT_INFO to work. Posting now to see if some of the earlier patches are ready to commit while I continue working on the latter half. Eric Blake (13):

I will be following up to this email with four separate threads each addressed to the appropriate single list, with proposed changes to: - the NBD protocol - qemu: both server and client - libnbd: client - nbdkit: server The feature in question adds a new optional NBD_INFO_ packet to the NBD_OPT_GO portion of handshake, adding up to 16 bits of information that the server can advertise to the