Posting this now to get feedback on the general idea; it would still
need to be polished into a form I'd feel happy committing, including
reworking 'qemu-nbd --list' to reuse the new NBD-specific QAPI type.

Based-on: <20190112175812.27068-1-eblake@redhat.com>
[0/19 nbd: add qemu-nbd --list]

Examples with this applied:
$ ./qemu-img info file
image: file
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 672K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
Protocol specific information:
    write zero: true
    discard zero: true
    discard: true
    align: 1
$ qemu-nbd file &
$ ./qemu-img info nbd://localhost:10809
image: nbd://localhost:10809
file format: raw
virtual size: 1.0M (1048576 bytes)
disk size: unavailable
Protocol specific information:
    flags:
    active contexts:
        [0]:
            name: base:allocation
            id: 0
    unknown flags: 1260

Eric Blake (3):
  block: Expose protocol-specific data to 'qemu-img info'
  file: Expose some protocol-specific information
  RFC: nbd: Expose protocol-specific information

 qapi/block-core.json | 87 +++++++++++++++++++++++++++++++++++++++++++-
 block/nbd-client.h   |  1 +
 block/file-posix.c   | 21 +++++++++++
 block/nbd-client.c   | 39 ++++++++++++++++++++
 block/nbd.c          |  3 ++
 block/qapi.c         |  7 ++++
 6 files changed, 156 insertions(+), 2 deletions(-)

-- 
2.20.1

On Thu, Jan 17, 2019 at 09:33:18AM -0600, Eric Blake wrote:
> Posting this now to get feedback on the general idea; it would still
> need to be polished into a form I'd feel happy committing, including
> reworking 'qemu-nbd --list' to reuse the new NBD-specific QAPI type.
> 
> Based-on: <20190112175812.27068-1-eblake@redhat.com>
> [0/19 nbd: add qemu-nbd --list]
> 
> Examples with this applied:
> $ ./qemu-img info file
> image: file
> file format: qcow2
> virtual size: 1.0M (1048576 bytes)
> disk size: 672K
> cluster_size: 65536
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>     refcount bits: 16
>     corrupt: false
> Protocol specific information:
>     write zero: true
>     discard zero: true
>     discard: true
>     align: 1
> $ qemu-nbd file &
> $ ./qemu-img info nbd://localhost:10809
> image: nbd://localhost:10809
> file format: raw
> virtual size: 1.0M (1048576 bytes)
> disk size: unavailable
> Protocol specific information:
>     flags:
>     active contexts:
>         [0]:
>             name: base:allocation
>             id: 0
>     unknown flags: 1260

One thing that occurs to me is that the qemu-img info output data is
getting larger & larger over time. Especially with LUKS, the format
specific data is quite huge. Adding protocol specific info makes it
larger again.

In retrospect, IMHO, it would have been nice to not show the format
specific info by default, requiring a --verbose arg. Assuming we don't
want to change default behaviour though, we might as well show protocol
specific info by default too.

I wonder though if we could benefit from a '-b' / '--brief' arg to make
it switch to show only the short common metadata, for people who want a
more concise output.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 1/17/19 10:06 AM, Daniel P. Berrangé wrote:

> One thing that occurs to me is that the qemu-img info output data is
> getting larger & larger over time. Especially with LUKS, the format
> specific data is quite huge. Adding protocol specific info makes it
> larger again.
> 
> In retrospect, IMHO, it would have been nice to not show the format
> specific info by default, requiring a --verbose arg. Assuming we don't
> want to change default behaviour though, we might as well show protocol
> specific info by default too.
> 
> I wonder though if we could benefit from a '-b' / '--brief' arg to make
> it switch to show only the short common metadata, for people who want a
> more concise output.

Do we have any backwards-compatibility guarantees on the output?  The
--output=json is obviously going to be verbose, no matter what. But that
argues that any machine parsing should use --output=json, and that
--output=human can change without regards to back-compat.  Or, we could
have --output=brief as a new third ofmt option (without having to burn
-b), and/or make --output=full be the verbose human form, and let the
default --output=human stick to brief by default.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org