[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [patch 0/2] QEMU maxcpus support
From: |
Avi Kivity |
Subject: |
[Qemu-devel] Re: [patch 0/2] QEMU maxcpus support |
Date: |
Tue, 23 Jun 2009 18:47:41 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
On 06/23/2009 06:07 PM, Jes Sorensen wrote:
On 06/23/2009 03:36 PM, Avi Kivity wrote:
On 06/23/2009 04:32 PM, Jes Sorensen wrote:
I should have said this at your previous post, but it only occurred to
me now: we could have -smp 4,maxcpus=65536 instead of a new parameter.
We could do that too, but is it really worth it? It seems to me
-maxcpus
is fine?
The trend is to consolidate related options into a single option, -to
-avoid -command -lines -with -too -many -dashes.
Ok, so how about this then?
DEF("smp", HAS_ARG, QEMU_OPTION_smp,
- "-smp n set the number of CPUs to 'n' [default=1]\n")
+ "-smp n,[maxcpus=cpus]\n"
-smp n[,maxcpus=cpus]
@@ -5550,12 +5551,29 @@ int main(int argc, char **argv, char **e
usb_devices_index++;
break;
case QEMU_OPTION_smp:
- smp_cpus = atoi(optarg);
+ {
+ char *p;
+ char option[128];
+ smp_cpus = strtol(optarg,&p, 10);
if (smp_cpus< 1) {
fprintf(stderr, "Invalid number of CPUs\n");
exit(1);
}
+ if (*p++ != ',')
+ break;
Won't this misparse "-smp 17z"?
+ if (get_param_value(option, 128, "maxcpus", p))
+ max_cpus = strtol(option, NULL, 0);
+ if (max_cpus< smp_cpus) {
+ fprintf(stderr, "maxcpus must be equal to or greater than "
+ "smp\n");
+ exit(1);
+ }
+ if (max_cpus> 255) {
+ fprintf(stderr, "Unsupported number of maxcpus\n");
+ exit(1);
+ }
break;
+ }
We really need a table-driven parser for options.
--
error compiling committee.c: too many arguments to function