On Tue, Feb 11, 2014 at 05:26:53PM +0100, Peter Krempa wrote:
Some remote filesystems are not accessible via the local filesystem
calls, but libvirt needs means to do operations on such files.
This patch adds internal APIs into the storage driver that will allow
operations on various networked and other filesystems.
---
Notes:
Version 5:
- changed error reporting scheme and re-documented
- fix indentation of makefile
- simplified conditions according to review
- fixed typos
docs/hvsupport.pl | 4 +-
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/check-drivername.pl | 1 +
src/driver.h | 30 +++++++-
src/libvirt_private.c | 180 +++++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_private.h | 61 ++++++++++++++++
src/libvirt_private.syms | 9 +++
I'm not really convinced we should be modifying any of these files
for this. None of this stuff is being exposed in either the wire
protocol or public API.
When we made the QEMU driver have a direct dep on the network
driver, so didn't wire that stuff up into the driver framework.
We just exported APIs in network/bridge_driver.h and had QEMU
call them. I'd expect the storage/storage_driver.h to just
export APIs we need in a similar manner.
That said, if we're finding we need these extra capabilities
from the storage driver, then this is a good sign that our
public API themselves need to also be enhanced. Admittedly
the latter is a bigger job, so we shouldn't block on that.
I do think we shouldn't wire any of this up into the driver
framework though.
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 :|