On Mon, Jan 30, 2012 at 08:23:36AM -0700, Eric Blake wrote:
On 01/30/2012 07:28 AM, Daniel P. Berrange wrote:
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
Here's what I was envisioning:
set my size to an absolute of 10M, regardless of whether it was previously 5M or 15M:
virStorageVolResize(vol, 10*1024*1024, SHRINK)
set my size to an absolute of 10M, but only if it does not shrink:
virStorageVolResize(vol, 10*1024*1024, 0)
set my size to a relative of 10M larger
virStorageVolResize(vol, 10*1024*1024, DELTA)
set my size to a relative of 10M smaller, provided it was at least 10M to begin with:
virStorageVolResize(vol, -10*1024*1024, DELTA|SHRINK)
You are proposing that the negative sign should be implied by the combination of DELTA|SHRINK; I guess I can live with that, since the other three use cases still work as-is, and DELTA|SHRINK is the only point where a negative value makes sense (and therefore where implying the negative is okay).
Shall I go ahead and write the patch?
Yep, that would be good. 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 :|