Re: [Libguestfs] [libnbd PATCH 00/13] libnbd patches for NBD_OPT_EXTENDED_HEADERS

[Laszlo Ersek]

On 12/04/21 00:17, Eric Blake wrote:
> Available here: 
> https://repo.or.cz/libnbd/ericb.git/shortlog/refs/tags/exthdr-v1
> 
> I also want to do followup patches to teach 'nbdinfo --map' and
> 'nbdcopy' to utilize 64-bit extents.
> 
> Eric Blake (13):
>   golang: Simplify nbd_block_status callback array copy
>   block_status: Refactor array storage
>   protocol: Add definitions for extended headers
>   protocol: Prepare to send 64-bit requests
>   protocol: Prepare to receive 64-bit replies
>   protocol: Accept 64-bit holes during pread
>   generator: Add struct nbd_extent in prep for 64-bit extents
>   block_status: Track 64-bit extents internally
>   block_status: Accept 64-bit extents during block status
>   api: Add [aio_]nbd_block_status_64
>   api: Add three functions for controlling extended headers
>   generator: Actually request extended headers
>   interop: Add test of 64-bit block status
> 
>  lib/internal.h                                |  31 ++-
>  lib/nbd-protocol.h                            |  61 ++++-
>  generator/API.ml                              | 237 ++++++++++++++++--
>  generator/API.mli                             |   3 +-
>  generator/C.ml                                |  24 +-
>  generator/GoLang.ml                           |  35 ++-
>  generator/Makefile.am                         |   3 +-
>  generator/OCaml.ml                            |  20 +-
>  generator/Python.ml                           |  29 ++-
>  generator/state_machine.ml                    |  52 +++-
>  generator/states-issue-command.c              |  31 ++-
>  .../states-newstyle-opt-extended-headers.c    |  90 +++++++
>  generator/states-newstyle-opt-starttls.c      |  10 +-
>  generator/states-reply-structured.c           | 220 ++++++++++++----
>  generator/states-reply.c                      |  31 ++-
>  lib/handle.c                                  |  27 +-
>  lib/rw.c                                      | 105 +++++++-
>  python/t/110-defaults.py                      |   3 +-
>  python/t/120-set-non-defaults.py              |   4 +-
>  python/t/465-block-status-64.py               |  56 +++++
>  ocaml/helpers.c                               |  22 +-
>  ocaml/nbd-c.h                                 |   3 +-
>  ocaml/tests/Makefile.am                       |   5 +-
>  ocaml/tests/test_110_defaults.ml              |   4 +-
>  ocaml/tests/test_120_set_non_defaults.ml      |   5 +-
>  ocaml/tests/test_465_block_status_64.ml       |  58 +++++
>  tests/meta-base-allocation.c                  | 111 +++++++-
>  interop/Makefile.am                           |   6 +
>  interop/large-status.c                        | 186 ++++++++++++++
>  interop/large-status.sh                       |  49 ++++
>  .gitignore                                    |   1 +
>  golang/Makefile.am                            |   3 +-
>  golang/handle.go                              |   6 +
>  golang/libnbd_110_defaults_test.go            |   8 +
>  golang/libnbd_120_set_non_defaults_test.go    |  12 +
>  golang/libnbd_465_block_status_64_test.go     | 119 +++++++++
>  36 files changed, 1511 insertions(+), 159 deletions(-)
>  create mode 100644 generator/states-newstyle-opt-extended-headers.c
>  create mode 100644 python/t/465-block-status-64.py
>  create mode 100644 ocaml/tests/test_465_block_status_64.ml
>  create mode 100644 interop/large-status.c
>  create mode 100755 interop/large-status.sh
>  create mode 100644 golang/libnbd_465_block_status_64_test.go
> 

I figured I should slowly / gradually review this series, and as a
*pre-requisite* for it, first apply the spec patch, and then read
through the spec with something like

$ git show --color -U1000

In other words, read the whole spec, just highlight the new additions.

Now, I see Vladimir has made several comments on the spec patch; will
those comments necessitate a respin of the libnbd series? If so, how
intrusive are the changes going to be? I'm hesitant to start my review
if significant changes are already foreseen.

Thanks,
Laszlo