2011/1/12 Eric Blake <eblake(a)redhat.com>:
On 01/12/2011 12:56 AM, Nikunj A. Dadhania wrote:
> Here is the patch, now the set calls are also ull.
> +++ b/tools/virsh.c
> @@ -2987,9 +2987,14 @@ cmdMemtune(vshControl * ctl, const vshCmd * cmd)
> params[i].value.l);
> break;
> case VIR_DOMAIN_MEMORY_PARAM_ULLONG:
> - vshPrint(ctl, "%-15s: %llu\n", params[i].field,
> - params[i].value.ul);
> + {
> + if (params[i].value.ul == VIR_DOMAIN_MEMORY_PARAM_UNLIMITED)
> + vshPrint(ctl, "%-15s: unlimited\n",
params[i].field);
> + else
> + vshPrint(ctl, "%-15s: %llu\n", params[i].field,
> + params[i].value.ul);
Do we want any back-compat considerations? That is, if a newer virsh is
talking to an older server, which still answered INT64_MAX>>10 instead
of the new VIR_DOMAIN_MEMORY_PARAM_UNLIMITED, should we recognize that
situation as another reason to print "unlimited"?
Why do we define VIR_DOMAIN_MEMORY_PARAM_UNLIMITED to UINT64_MAX
anyway when currently INT64_MAX >> 10 is supported to mean unlimited?
Why do we want to complicate all applications that use the memory
parameter API, because they effectively need to interpret two values
as unlimited? Are there any really compelling reasons to change the
value that means unlimited?
Another question: How do I set a memory parameter back to unlimited?
Do I need to specify INT64_MAX >> 10 as numeric value in virsh?
Matthias