[Libguestfs] [PATCH v2 00/23] Reimplement many daemon APIs in OCaml.

[Richard W.M. Jones]

On Thu, Jul 27, 2017 at 06:15:28PM +0200, Pino Toscano wrote:
> On Friday, 21 July 2017 22:36:04 CEST Richard W.M. Jones wrote:
> > - Generating:
> >     external available : unit -> bool = "guestfs_int_daemon_optgroup..."
> >   etc.  It's hard to generate these functions and have them added to the
> >   correct modules (since the OCaml modules are hand-written, and it's
> >   awkward to include generated bits in them).
> 
> My suggestion was to create a single OptGroups module, with all the
> foo_available functions.  Instead of all the functions, another option
> could be like the following:
> 
>   type available_feature =
>     | ACL
>     | AUGEAS
>     ...
> 
>   val available : available_feature -> bool

OK maybe we can fix that later as it only affects 2 modules.

> > Other notes:
> > 
> > - daemon must be linked to -ldl -lm because the OCaml runtime
> >   (libasmrun.so) depends on both.
> 
> I don't understand, at least here it links with them:
> 
>   $ readelf -d /usr/lib64/ocaml/libasmrun_shared.so | grep NEEDED
>   0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
>   0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>   0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
> 
> So unless we use libdl and libm explicitly, we don't need to care about
> which libraries are used by libasmrun.so.  Am I missing anything here?

We're linking with the static runtime (libasmrun.a).

Now we certainly could link with the shared runtime but that would
pull the OCaml compiler into the appliance, or at least it would with
the current state of the packaging on Fedora.  Also libasmrun_shared
is only supported in OCaml >= 4.02
[https://caml.inria.fr/mantis/view.php?id=6693]

The shared runtime is slower because of something to do with ELF which
I don't exactly recall now.

> > - Structs must be repeated in *.mli files because you can't use OCaml
> >   ‘include’ to pick up single structs from another module.  However
> >   the structs are still type checked by the compiler, so we cannot
> >   write incorrect / untyped code this way.
> 
> Not even by referencing the module?  Ie. Structs.btrfsvolumeinfo
> (or so), like done eg in builder/*_parser.mli?

Sure we could reference it, but in this case I'm actually
(re-)exporting the structs from the module, so that when calling these
functions from other parts of the daemon you could write:

  (Btrfs.btrfs_subvolume_list m).Btrfs.btrfssubvolume_id

Maybe that's not a very good reason, but that's the reason.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top