On Mon, Jan 30, 2012 at 5:27 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > 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. FWIW +1 from my side too. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list