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