Re: [Libvir] [PATCH] #4: Change interface between xen_unified & its underlying drivers

Daniel Veillard wrote: I didn't explain it well, but here's why: At the moment if you want to find out how, say, "reboot" is implemented you need to first of all examine all 5 underlying drivers to see which have a non-NULL function in that slot in the driver table. Secondly you need to examine xen_unified.c in two places: at the top of the file to see what order the backend drivers are normally called in, then at the xenUnifiedDomainReboot function itself to see if the function follows that order or is one of the exceptions that does its own thing. So you have to examine 7 places in the code. I want to bring that all together so that you only have to examine one place (xenUnifiedDomainReboot) to see how it is implemented. The fact that at the moment virDriver is a dual-purpose structure was just about convenience when I originally implemented xen-unified. It makes no particular sense to have the interface between libvirt.c and drivers be the same as the xen-internal interface between xen_unified.c and its underlying drivers. In dynamic libs these functions will be hidden because of the libvirt_syms file. In static libvirt.a the functions will be exported, but they are already exported at the moment via the driver table, so there is no practical difference. I really don't think the patch as it stands is a major change though - I mean the calls are still going through a structure, it just happens to be a xen-specific structure rather than the virDriver structure. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903