|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options. |
Date: | Tue, 21 Jul 2009 15:59:13 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |