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

[Gerd Hoffmann <kraxel@redhat.com>]

On 07/21/09 17:58, Kevin Wolf wrote:
> Gerd Hoffmann schrieb:
>> On 07/17/09 09:03, Kevin Wolf wrote:
>>> Gerd Hoffmann schrieb:
>>>> This stores device parameters in a better way than unparsed strings.
>>>>
>>>> New types:
>>>>     QemuOpt       -  one key-value pair.
>>>>     QemuOpts      -  group of key-value pairs, belonging to one
>>>>                      device, i.e. one drive.
>>>>     QemuOptsList  -  list of some kind of devices, i.e. all drives.
>>> What about having the options typed like I did in qemu-option.[ch]?
>>>
>>> In general qemu-option seems to do more parsing/checking than QemuOpts
>>> does, on the other hand it's not yet generic enough to suit everything.
>> Yup, qemu-options has all in one struct, which fails on multiple
>> instaces (i.e. two drives).
>
> 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.

>> 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.

cheers,
   Gerd