Libguestfs - Jun 2023 - [libnbd PATCH v3 03/22] protocol: Add definitions for extended headers

On Tue, May 30, 2023 at 05:48:25PM +0200, Laszlo Ersek
wrote:
> BTW I'm foreseeing a problem: if the extended block descriptor can
> provide an unsigned 64-bit length, we're going to have trouble exposing
> that in OCaml, because OCaml only has signed 64-bit integers. So that's
> going to reproduce the same issue, only for OCaml callers of the *new* API.
> 
> I can see Eric's series includes patches like "ocaml: Add example
for
> 64-bit extents" -- I've not looked at those yet; for now I'm
just
> wondering what tricks we might need in the bindings generator. The
> method seen in the "middle patch" above won't work; we
don't have a
> native OCaml "i128" type for example that we could use as an
escape
> hatch, for representing C's uint64_t.
I think that's OK because disk sizes are already limited to
2^63 - 1 by the kernel (and for qemu even less than that).
The OCaml bindings return a (signed) int64 for NBD.get_size.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

On 6/7/23 12:00, Richard W.M. Jones wrote:
> On Tue, May 30, 2023 at 05:48:25PM +0200, Laszlo Ersek wrote:
>> BTW I'm foreseeing a problem: if the extended block descriptor can
>> provide an unsigned 64-bit length, we're going to have trouble
exposing
>> that in OCaml, because OCaml only has signed 64-bit integers. So
that's
>> going to reproduce the same issue, only for OCaml callers of the *new*
API.
>>
>> I can see Eric's series includes patches like "ocaml: Add
example for
>> 64-bit extents" -- I've not looked at those yet; for now
I'm just
>> wondering what tricks we might need in the bindings generator. The
>> method seen in the "middle patch" above won't work; we
don't have a
>> native OCaml "i128" type for example that we could use as an
escape
>> hatch, for representing C's uint64_t.
> 
> I think that's OK because disk sizes are already limited to
> 2^63 - 1 by the kernel (and for qemu even less than that).
> The OCaml bindings return a (signed) int64 for NBD.get_size.
Under patch#7 yesterday, I made a proposal for "armoring" at least one
instance / direction of the uint64_t <-> int64 conversion. It raised an
interesting problem: raising OCaml exceptions in such C functions that
are *not* directly called by the OCaml runtime. Comments would be much
appreciated in that subthread!

(On a tangent: I've also noticed we use CAMLparam0() & friends in some
of our functions that are *not* directly called by the OCaml runtime.
They certainly run on the OCaml runtime's stack, but there's at least
one intervening stack frame where the C-language function is provided by
us. Now I know we must use CAMLparam0() in our *outermost* such
function, but what about the further functions (inner C-language
functions) that our outermost function calls in turn? I think the inner
functions are at liberty not to use CAMLparam0() -- otherwise, our
functions couldn't even call normal C library functions!)

Thanks,
Laszlo