Re: [Xen-devel] [PATCH,RFC]: Introduce libxl_domain_create()

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

On Tue, 2010-12-21 at 11:35 +0000, Ian Jackson wrote:
> Gianni Tedesco writes ("Re: [Xen-devel] [PATCH,RFC]: Introduce 
> libxl_domain_create()"):
> > On Fri, 2010-12-17 at 09:06 +0000, Ian Campbell wrote:
> > > Should be in IDL so it gets a destructor? Could require adding an Array
> > > construct to handle the foo + num_foo style stuff.
> > 
> > I've thought about that and rejected it because C arrays don't map to
> > anything useful in language bindings. It makes sense to me to keep this
> > as a builtin and use functions to fill these domain creation related
> > structures in for us.
> 
> Arrays map perfectly well to a C pointer and a length.  If you want to
> do automatic expansion you need a separate allocated length too, which
> is probably worthwhile.

Python, for example, has no concept of an array nor any remotely similar
data structure.

The way I have developed the current xl binding is that C-structs are
embedded inside python objects which wrap them. To be fair I could
probably auto-generate list <-> array marshalling functions to go each
way so it's not impossible.

> > But then what you get is like two versions of:
> >  - libxl_device_add_(nic|block|etc)
> > One for a live domain and one for domain creation.
> 
> I think that's fine, particularly if they take the same struct.
> 
> > I have been toying with the idea of using polymorphism (is that what
> > it's called?) So that such a function would multiplex to different
> > implementations depending on whether this is a live domain or a
> > description of a domain for creation. It might need a bit of thinking
> > through as how it would be used.
> 
> Urgh.

Fair enough, I didn't expect a positive response to that one. But I
mentioned to Stefano that that's the sort of interface I'll end up
writing in python and he suggested that it be done that way in C so that
the API's people are using are similar.

Gianni


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