[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [PATCH] Refactor xend_internal.c block device detection



On Tue, Oct 16, 2007 at 02:13:04PM +0100, Richard W.M. Jones wrote:
> This patch is a little bit esoteric, but I need it for something I'm 
> working on at the moment.
> 
> At the moment the code in xend_internal.c: xend_parse_sexp_desc parses 
> the domain sexpr directly into XML.  This makes it rather hard to just 
> get a list of block devices without repeating the same code.  So here 
> I've factored out the common code for parsing block devices into a 
> separate function and callback.

  You really need a callback ? This makes code harder to understand 

> +            /* Call the callback function. */
> +            ret = fn (conn, data, isBlock, cdrom, isNoSrcCdrom,
> +                      drvName, drvType, src, dst, mode);

This adds flexibility but is a bit convoluted, what do you need this for ?

> There are a couple of small changes that you should be aware of: (1) The 
> <devices> list may be returned in a different order (specifically, block 
> devices are always returned first).  (2) We iterate over the root nodes 
> of the sexpr twice (once for block devices, once for vifs and vfbs). 
> But the sexpr is small and in-memory so this shouldn't be a problem 
> compared to having to do the HTTP request to xend to get it in the first 
> place.

  Having disks presented first in the resulting XML is a bit cleaner IMHO
and I don't think the double scan of teh sexpr is a big deal, really.
I'm more wondering about what you need to achieve that really needs a callback
based interface.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]