On Mon, Jan 30, 2012 at 02:25:19PM +0000, Daniel P. Berrange wrote:
On Mon, Jan 30, 2012 at 07:18:06AM -0700, Eric Blake wrote:
On 01/30/2012 04:08 AM, Daniel P. Berrange wrote:
On Fri, Jan 27, 2012 at 05:28:15PM -0700, Eric Blake wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
Add a new function to allow changing of capacity of storage volumes. Plan out several flags, even if not all of them will be implemented up front.
+typedef enum { + VIR_STORAGE_VOL_RESIZE_ALLOCATE = 1 << 0, /* force allocation of new size */ + VIR_STORAGE_VOL_RESIZE_DELTA = 1 << 1, /* size is relative to current */ + VIR_STORAGE_VOL_RESIZE_SHRINK = 1 << 2, /* allow decrease in capacity */ +} virStorageVolResizeFlags; + +int virStorageVolResize (virStorageVolPtr vol, + long long capacity, + unsigned int flags);
Why has this changed from 'unsigned long long' to just 'long long'.
Because of VIR_STORAGE_VOL_RESIZE_DELTA and VIR_STORAGE_VOL_RESIZE_SHRINK. That is,
virStorageVolResize(vol, -10 * 1024 * 1024, DELTA|SHRINK)
is a valid call to shave off 10 MiB of data.
Isn't that rather redundant. Either you need a negative size, or you need a SHRINK flag. If you have a shrink flag, then we don't need a signed int.
In fact since our existing virDomainBlockResize API is already using unsigned long long, I'd say we should do shrinkage solely based off the SHRINK flag, and *not* require a negative size as well 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 :|