This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 2 of 5] tools: ocaml: move the nic_info record in

To: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Subject: 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
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 29 Mar 2011 09:42:36 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 29 Mar 2011 01:43:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <45326ad6a0d396bfcd3c.1301315196@ely>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <patchbomb.1301315194@ely> <45326ad6a0d396bfcd3c.1301315196@ely>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

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

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 > 
(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.


[0] i..we

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>