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

[Kevin Wolf <kwolf@redhat.com>]

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.

>> Maybe a combination of both would be the right thing?
> 
> I think the question is here how and when we want to do the parsing.
> 
> 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.

Kevin