qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V5 01/12] NUMA: add NumaOptions, NumaNodeOptions


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH V5 01/12] NUMA: add NumaOptions, NumaNodeOptions and NumaMemOptions
Date: Wed, 17 Jul 2013 17:54:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 17/07/2013 17:45, Laszlo Ersek ha scritto:
>> Yes, though I guess Wanlong could do this by himself.  A more
>> interesting prototype is "how to add code to OptsVisitor that parses
>> intervals when it sees ['int']", and this where you can help the most.
> 
> Do you want each element of the range present in the flat list, or just
> the boundaries? (The above example, ie [3..4]U[9..10] doesn't
> distinguish between these two.)

It should be a real list.

> If the list contains the boundaries only, that's more frugal but
> requires smarter code. If the list contains all elements, then big
> ranges will result in huge lists (which are then easy to handle piecewise).

Huge lists wouldn't be a problem, I think.

> Do you also want a<=b checking for [a,b]? (That would imply "inclusive"
> on both sides and not allow empty sets easily.)
> 
> This is going to be a huge hack, but I can already express the condition
> "I'm in a list and looking for the next element as int" in the code. So
> maybe I could force some more state into OptsVisitor (specifically
> opts_type_int()/opts_type_uint64() and lookup_scalar()) and fake extra
> elements.

Yeah, I guessed something like that.

> Better: I could pop "a-b" off "ov->repeated_opts", return "a" (after
> parsing), and push back "b". Then "b" would not differ from the current
> "individual int" case, and I wouldn't have to add extra state to
> maintain between calls.
> 
> You just torpedoed planned review efforts for today / tomorrow :)

:)

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]