similar to: [libnbd PATCH v2] nbdsh: Prefer --uri over --connect

Typing nbdsh --con (the minimum to get an unambiguous prefix for --connect, different from --command) is annoying compared to having a short option. Since it takes a URI as an argument, using -u seems like a reasonable mnemonic. --- sh/nbdsh.pod | 6 ++++-- python/nbdsh.py | 2 +- sh/test-context.sh | 8 ++++---- sh/test-pattern.sh | 2 +- 4 files changed, 10 insertions(+), 8

We decided to not request the "base:allocation" context by default (if a client wants to use block_status on a different context, then they'd have to get any default request out of the way); however, block status is useless without at least one meta context. This adds a convenience knob for requesting that, and has the nice benefit of working with the --connect command line option

Similar to --base-allocation, this is a common enough configuration that cannot be performed with -c when using --uri, but which makes life easier in scripting. And like --base-allocation, I'm starting with only a long option spelling, rather than burning a short option letter. --- sh/nbdsh.pod | 21 +++++++++++++++++++-- python/nbdsh.py | 6 ++++++ sh/test-context.sh | 32

v1 was here: https://listman.redhat.com/archives/libguestfs/2022-October/030216.html Since then, I've incorporated changes based on Rich's feedback: swap order of patches 2 and 3 less change in patch 1 (including no unsafe eval(%s) for --uri) in patch 2, include -c in list of snippets to store, and use dict of lambdas to map back to the desired action Eric Blake (3): nbdsh:

Ultimately, I'd like to add a unit test covering our recent fix for handling globals from consecutive -c, but let's start with a simple test that --help output is sane. Sanity includes a mention of the man page for more details (similar to nbdkit --help, although I couldn't figure out how to make python's argparse output that sentence last). --- python/nbdsh.py | 3 ++-

Hi folks, I've discussed my desire to have multi location debug info support in LLVM IR with some of you before (and others - apologies if I forgot to CC you). I finally found some time to write down my thoughts about how this should work at the IR level and worked out the proposal below. Please let me know if this a) also does what you want out of it, b) seems like a sane way to encode

On 9/5/20 8:56 AM, Eric Blake wrote: > Thinking about it more, it is probably easiest to just declare that we > guarantee the cleanup callback is called regardless of failure mode, for > all closures, and that we merely had a memory leak in earlier libnbd > releases.  Yes, this means that we have a risk of older apps hitting a > double free if they cleaned up after a cookie of

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

Previously, the examples fetch-first-sector and get-size in rust/examples only accepted a unix socket as argument. This commit makes it possible to provide a URI as well. --- rust/examples/fetch-first-sector.rs | 15 +++++++++++---- rust/examples/get-size.rs | 20 +++++++++++++++----- 2 files changed, 26 insertions(+), 9 deletions(-) diff --git a/rust/examples/fetch-first-sector.rs

On platforms which support it (only Linux currently) nbdkit can act as a vsock server. Guests running on the host see a raw NBD socket which it can connect to by opening an AF_VSOCK connection. (Although only libnbd supports this). The current limitations are: * nbdkit can only act as a host (cid == VMADDR_CID_HOST == 2). * There is no access control. Any guest which has vsock enabled can

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

When using nbdsh for scripting, it is convenient to let nbdsh fail with status 1 when encountering an API failure. However, doing so by letting the nbd.Error exception leak all the way causes ABRT (at least on Fedora 32 with abrt-python3-handler installed) to assume the program crashed from a programming error, and needlessly complicates clients to have to add try: blocks. Better is if nbdsh

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

When using nbdsh for scripting, it is convenient to let nbdsh fail with status 1 when encountering an API failure. However, doing so by letting the nbd.Error exception leak all the way causes ABRT (on Fedora 32 at least) to assume the program crashed from a programming error, and needlessly complicates clients to have to add try: blocks. Better is if nbdsh itself prints the same stack trace that

nbdsh has some advantages over qemu-io: - scriptable - allows us to more finely control NBD commands, such as making subsector-sized requests and controlling how many commands are sent on the wire - can write controlled patterns - can read NBD export flags --- README | 2 ++ tests/Makefile.am | 5 +++-- tests/test-error0.sh | 13 +++++++------

Add coverage for the previous patch. Each retry of .extents must be into a fresh extents object, to avoid mismatch between provided and expected offsets. Signed-off-by: Eric Blake <eblake at redhat.com> --- tests/Makefile.am | 2 + tests/test-retry-extents.sh | 114 ++++++++++++++++++++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100755

On 5/20/20 7:50 AM, Richard W.M. Jones wrote: > The old test relied on issuing an asynchronous command to a qemu-io > subprocess, requiring a sleep to ensure that the command had been > carried out. ‘sleep 1’ was not long enough on s390x as you can see > from this partial trace: Nice analysis. > Here are still connecting to nbdkit from "connection A", long after >

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

Test that we can script the read of a specific pattern from nbdkit. Also, test that we can concatenate global functions through consecutive -c. This test fails if commit d6cbd130 is reverted. --- sh/Makefile.am | 5 ++++- sh/test-dump.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 1 deletion(-) create mode 100755 sh/test-dump.sh diff --git

On Tue, Jan 31, 2023 at 01:33:25PM +0200, Nir Soffer wrote: > On Tue, Jan 31, 2023 at 12:34 AM Richard W.M. Jones <rjones at redhat.com> wrote: > > > > On Fri, Nov 04, 2022 at 04:18:31PM -0500, Eric Blake wrote: > > > Document all options in --help output. If -n is not in use, then > > > enhance the banner to print the current state of h, and further tailor