On Thu, Oct 31, 2013 at 12:46:07PM -0600, Eric Blake wrote: > On 10/31/2013 12:34 PM, Daniel P. Berrange wrote: > > > > > IIUC, this is still going to be introducing a direct code path dependancy > > between the QEMU and storage driver code though. > > No, src/qemu would still get backing chain details via src/util, the way > it has always done. Only src/util has to have the magic to call into > src/storage backends (if the right backend is present, chase the backing > chain of the network disk; if absent, forcefully assume raw as is > already currently done). > > > > > Currently src/qemu depends only on code in src/util & src/conf[1]. For > > the storage pool bits, it can call indirectly via src/libvirt.c APIs, but > > it does not call anything in src/storage/ directly. I really want this > > to remain that way, because avoiding direct calls is key to enabling > > us to split libvirtd up into separate daemons per driver in the future. > > > > Daniel > > > > [1] Yes, there's a dep on src/network too, which i was never at all happy > > about, and which needs to be refactored / removed in some manner in > > the future > > This is a useful discussion, because I don't want to be developing code > that violates layering constraints. So, am I on the right track by > allowing src/util to call into src/storage backends, or is the only > proper way to do that to have src/util call in to src/libvirt.c APIs > which then call into src/storage indirectly? src/util shouldn't have any compile time dependancy on src/storage, or indeed any other directory. You could conceivably do it indirectly, by having src/storage register some kind of plugin with src/util at startup. That way it is only a runtime dep. > How does this compare to src/qemu/qemu_process.c, using > conn->secretDriver->secretGetValue(, > VIR_SECRET_GET_VALUE_INTERNAL_CALL), as a means of calling into > src/secret indirectly but without going through src/libvirt.c API? Again, that's a runtime only dep. So if the libvirt_driver_secret.la was not installed, it would not be fatal - the API calls would just get a runtime error. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list