search for: nbd_info_description

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 write if it can just assume the client already passed in the canonical name), we don...

Exposing a description in single mode is harder: we'd have to request NBD_INFO_DESCRIPTION during NBD_OPT_GO. For now, the API only supports descriptions in list mode. --- info/info-list-json.sh | 3 ++- info/info-list.sh | 3 ++- info/nbdinfo.c | 21 ++++++++++++++++----- 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/info/info-list-json.sh b/info/info-...

...aking .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_INFO_NAME, we can also support NBD_INFO_DESCRIPTION; but while we map "" to a canonical name prior to calling .open, getting the description makes more sense after the connection is established, alongside .get_size. --- I obviously need to finish the code to go with this, but here's where I would like to see the API before we finalize...

...er/protocol-handshake-newstyle.c index 6e5f3822..dd4ca601 100644 --- a/server/protocol-handshake-newstyle.c +++ b/server/protocol-handshake-newstyle.c @@ -156,6 +156,37 @@ send_newstyle_option_reply_info_export (uint32_t option, uint32_t reply, return 0; } +/* Can be used for NBD_INFO_NAME and NBD_INFO_DESCRIPTION. */ +static int +send_newstyle_option_reply_info_str (uint32_t option, uint32_t reply, + uint16_t info, const char *str, + size_t len) +{ + GET_CONN; + struct nbd_fixed_new_option_reply fixed_new_option_reply; + struct nbd_f...

..._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

..._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) */ } NBD_ATTRIBUTE_PACKED; -/* New-style...

...rab 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_INFO_NAME, we can also support NBD_INFO_DESCRIPTION; but > while we map "" to a canonical name prior to calling .open, > getting the description makes more sense after the connection > is established, alongside .get_size. > --- > > I obviously need to finish the code to go with this, but here's where > I would lik...

An incremental improvement on top of listing exports. I still think it's worth experimenting with revisiting how our API for list mode should actually work [1] (so that we can reuse a single connection for both grabbing the list and finally using NBD_OPT_GO), but this change was easier to whip together while still thinking about that. [1]

Necessary when writing a client that wants to avoid unnecessary EINVAL errors from sending unaligned requests. At some point, we may want to add synchronous convenience API wrappers that do request splitting or read-modify-write to obey server constraints while still appearing to the library client as accepting any possible request. But such a wrapper should only be synchronous and not copied to

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

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

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

...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_INFO_NAME, we can also support NBD_INFO_DESCRIPTION; but > >while we map "" to a canonical name prior to calling .open, > >getting the description makes more sense after the connection > >is established, alongside .get_size. > >--- > > > >I obviously need to finish the code to go with this, but here'...

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):

This rounds up the remaining bugs that I originally identified in: https://www.redhat.com/archives/libguestfs/2020-July/msg00153.html Eric Blake (4): api: Permit export list APIs when Connected info: Support --list with serializing servers info: Fix --json output when list size != 1 info: Permit --size --json generator/API.ml | 6 +++--- info/info-list-json.sh | 9 +++++++++

...ed 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 eflags; /* per-export flag...

More patches on the way for improving .list_exports signature and adding .export_description, but this is the promised code showing why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we could either add new API to take the boilerplate from: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { CLEANUP_FREE char *tmp = nbdkit_realpath (value);

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