On 06/21/2013 12:02 AM, Bandan Das wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> Il 20/06/2013 15:26, Eduardo Habkost ha scritto: >>> On Thu, Jun 20, 2013 at 11:52:42AM +0200, Paolo Bonzini wrote: >>>> Il 20/06/2013 11:30, Igor Mammedov ha scritto: >>>>>>>>>>> So, basically the format seemed easier to work with if we are >>>>>>>>>>> thinking >>>>>>>>>>> of using QemuOpts for -numa. Using -cpu rather than cpus probably >>>>>>>>>>> makes it less ambiguous as well IMO. However, it's probably not a >>>>>>>>>>> good idea >>>>>>>>>>> if the current syntax is well established ? >>>>>>> >>>>>>> libvirt uses the "cpus" option already, so we have to keep it working. >>>>> Sure, we can leave it as it's now for some time while a new interface is >>>>> introduced/adopted. And than later deprecate "cpus". >>>> >>>> So, you used a new name because the new behavior of "-numa >>>> node,cpus=1-2,cpus=3-4" would be incompatible with the old. >>> >>> I don't think anybody uses "cpus=1-2,cpus=3-4" today, so I believe we >>> can change its behavior. The problem was to get agreement on the syntax >>> to represent multiple CPU ranges. >> >> Ok. I think almost everyone agreed on "cpus=1-2,cpus=3-4", which is >> basically what Bandan's patch does minus s/cpu/cpus/. It matches what >> already happens with other options (SLIRP), so it's hardly surprising. > > Good, so should I spin a new version with "cpus" ?
I already merged your patch to my patch set "Add support for binding guest numa nodes to host numa nodes" since I should base on that. Thanks, Wanlong Gao > > Also note that this patch actually doesn't add any extra code to support > multiple cpus arguments. It all happens automatically as part of conversion to > QemuOpts. So, if we need to revisit the syntax later, we can always do that. > > Bandan >> Let's go on with that. >> >> Paolo >> >>>> Personally I don't think that's a problem, but I remember a long >>>> discussion in the past. Igor/Eduardo, do you remember the conclusions? >>> >>> I don't remember seeing the discussion reach any conclusion, >>> unfortunately. >>> > >
