Re: [Libguestfs] [virt-v2v PATCH 2/3] lib/nbdkit: add the "Nbdkit.get_disk_allocated" helper function

On 12/08/21 16:21, Richard W.M. Jones wrote: > On Wed, Dec 08, 2021 at 01:20:49PM +0100, Laszlo Ersek wrote: >> Add the "Nbdkit.get_disk_allocated" helper function, which calculates the >> number of allocated bytes in an output disk image, through a corresponding >> NBD server connection. >> >> Original "NBD.block_status" summation example code by Rich Jones >> (thanks!), chunking, metadata context simplification, and virt-v2v >> integration by myself. Chunking added because "NBD.block_status" is not >> 64-bit clean just yet (Eric Blake is working on it). >> >> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2027598 >> Signed-off-by: Laszlo Ersek <lersek(a)redhat.com&gt; >> --- >> lib/nbdkit.mli | 8 ++++++ >> lib/nbdkit.ml | 30 ++++++++++++++++++++ >> 2 files changed, 38 insertions(+) >> >> diff --git a/lib/nbdkit.mli b/lib/nbdkit.mli >> index 825755e61dbe..03107dab109d 100644 >> --- a/lib/nbdkit.mli >> +++ b/lib/nbdkit.mli >> @@ -117,3 +117,11 @@ val with_connect_unix : socket:string -> >> in [meta_contexts] requested (each of which is not necessarily supported by >> the server though). The connection is torn down either on normal return or >> if the function [f] throws an exception. *) >> + >> +val get_disk_allocated : dir:string -> disknr:int -> int64 option >> +(** Callable only in the finalization step. [get_disk_allocated dir disknr] >> + examines output disk [disknr] through the corresponding NBD server socket >> + that resides in [dir]. Returns the number of bytes allocated in the disk >> + image, according to the "base:allocation" metadata context. If the context >> + is not supported by the NBD server behind the socket, the function returns >> + None. *) > > This really is the right function, wrong module. > > Since it only applies to output modules, the logical place is in > output/output.ml, where there are already a bunch of random helper > functions. That's precisely where I put it first (given that we have "get_disks" there too!). However, I proved simply unable to *call* the function, from "lib/create_ovf.ml", in the next patch!

I tried "Output.get_disk_allocated", and I got a weird compilation failure, even though the function was properly declared in "output.mli".

At that point, I couldn't decide if I was missing something about the tricky "first class modules" thing, or if it was really a layering violation to call an Output function from a *lower level* utility function (such as "create_ovf" in "lib/create_ovf.ml").