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

[Gerd Hoffmann <kraxel@redhat.com>]

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

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

comments?

cheers,
   Gerd