|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition of libxl_domain_config into the IDL
On Tue, 2012-04-24 at 18:57 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2] RFC: libxl: move definition
> of libxl_domain_config into the IDL"):
> > RFC: libxl: move definition of libxl_domain_config into the IDL
> >
> > This requires adding a new Array type to the IDL.
> >
> > DO NOT APPLY. This is 4.3 material.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>
> > + idl.Array.len_var contains an idl.Field which is added to the parent
> > + idl.Aggregate and will contain the length of the array.
>
> Why does the Array not automatically invent a "num_<foo>" field ?
> Surely there is no benefit to having non-systematically named (or
> typed) array count fields ?
That would be good but currently the Array type doesn't see the name of
the member in the containing struct:
Struct("thing", [
("disks", Array(libxl_device_disk, "num_disks")),
])
We have a similar problem with the KeyedUnion which similarly ought to
be able to at least default keyvar_name to something.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |