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? 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? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
