Re: [Xen-devel] [PATCH 2 of 5] tools: ocaml: move the nic_info record into a module to the field labels live in a separate namespace

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2011-03-28 at 13:26 +0100, Dave Scott wrote:
> # HG changeset patch
> # User David Scott <dave.scott@xxxxxxxxxxxxx>
> # Date 1301314652 -3600
> # Node ID 45326ad6a0d396bfcd3c83d209ab7a19d6499896
> # Parent  85361e3dab12827c6321931c9e09d02fb22578ee
> tools: ocaml: move the nic_info record into a module to the field
> labels live in a separate namespace.
> 
> Otherwise the redefinition of fields like "backend_domid" "devid" et
> al make the records un-instantiable.

I suppose it is the case that all the defined data types ought to have
this done? Doing it for all but one of the types which clash would be
confusing...

I guess that Foo.t is an ocaml idiom, so I won't comment on it ;-)

The libxl type which this structure mirrors is called libxl_device_nic
so perhaps to aid future autogeneratability (something I was working on
at the hackathon) we could use module Device_nic? I'm assuming the full
name as external modules see it would be Xl.Device_nic, if not perhaps
Xl_device_nic?

I ran into some wrinkles with the autogenerated bindings since ocaml
appears to lack a #include style syntax which allow one to easily inject
a glob of generated code into the middle of an otherwise hand-written
source code file. I got around this with:
        sed -e '/^(\* @@LIBXL_TYPES@@ \*)$$/r_libxl_types.mli.in < xl.mli.in > 
xl.mli
(I'm not sure if I am proud of this or not).

Does putting the datatypes into a module (or modules) ease this at all?
It looks like we might end up with device_nic.ml, device_disk.ml etc for
each generated type, which is not ideal, and probably not better than
using sed.

Having moved the data type into a module does it also make sense to move
the relevant functions too e.g. Xl.Device_nic.add : Nic_info.t -> domid
-> unit etc?

Unless you can use the "module Foo" syntax multiple times to extend the
contents of the module (i.e. to do the autogenerated stuff separately
from the handwritten stuff so that it can all be included at once) this
looks like it would have the same issues with putting each module in a
separate file I worried about above.

> -external nic_add : nic_info -> domid -> unit = "stub_xl_nic_add"
> +external nic_add : Nic_info.t -> domid -> unit = "stub_xl_nic_add"
>  external nic_remove : disk_info -> domid -> unit = "stub_xl_nic_remove"

One of these parameters is not like the others ;-0 I see you caught that
in patch 5/5.

Ian.

[0] i..we


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel