Re: [libvirt] [PATCH] conf: use proper maximum for parsing memory values

On 10/30/2014 10:23 AM, Eric Blake wrote: Looking a bit deeper, commit 4888f0fb5 was where we changed all internal tracking to use unsigned long long; but we still have the public API virDomain{Get,Set}MaxMemory that are tied to 'unsigned long'. I guess what I was trying to do in 2e22f23 (both in 2012) was to ensure that virDomainGetMaxMemory would never have to fail due to overflow, by capping the input to something that would fit in the output. And we still got it wrong then, since commit 19e7c04 (in 2013) fixed a case where 32-bit hosts were truncating incorrectly. Meanwhile, it looks like virDomain{Get,Set}MemoryParamters have ALWAYS used ullong. But this interface doesn't report max memory - so we still have to live with the fact that there is currently no interface for the user getting at max memory other than crippled API. Maybe the solution is to enhance virDomain{Get,Set}MemoryParameters to be a superset of the older APIs of virDomain{Get,Set}MaxMemory, and teach the older APIs to fail with VIR_ERR_OVERFLOW when the value can only be passed through the newer API. Or maybe the solution is to make virDomainParseMemory add a bool parameter that says whether the caller is old-style (32-bit cap) or new-style (full 64-bit width), and set the maximum according to that information. That's probably the easiest for doing right now. I can take a stab at it, since it was my commit in 2012 that originally introduced the weird 32-bit cap even when parsing a 64-bit field. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org