Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options.

[Kevin Wolf <kwolf@redhat.com>]

Gerd Hoffmann schrieb:
> On 07/21/09 17:58, Kevin Wolf wrote:
>> Right, this is one of the points I thought of. Another one is that there
>> are some variants in use with a required first parameter that doesn't
>> have a name (like nic in -net nic,model=xyz). I guess, there are some
>> more details that are not completely covered.
> 
> -net is a very special beast as the list of parameters is very different 
> for -net nic, -net tap, -net user, ...
> 
> So it probably makes sense to have a separate QemuOptsList for each of 
> them instead of storing a "type=[nic|tap|user]" into a common net list.

I agree, -net should be done different, so this was a bad example. But I
thought we had more of them. -boot is an option with implicit first
parameter name, and there was at least a discussion on making -smp
another one. There might be more.

Or do you want to keep the old parsing code for these options?

>>> We could do it early, when parsing/storing the values.  QemuOptsList
>>> could get a QEMUOptionParameter-like struct instead of the simple
>>> valid[] array.  QemuOpts->value would become a union.  qemu_opt_set
>>> handles parsing and stores in the union.  qemu_opt_get() would move to
>>> qemu_opt_get_$type() and it would return the value from the matching
>>> union member.
>>>
>>> We could do it late, when using the values.  Parsing would happen
>>> directly in qemu_opt_get_$type().
>> I would prefer doing it in a central place, so that you don't depend on
>> the user to actually trigger checks. But probably both would work.
> 
> Yep, so we have one place where we catch parse errors instead of having 
> each callsite to check for qemu_opt_get_$type() failures.

Sounds great. Now it just needs to be implemented. ;-)

Kevin