[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and pars
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options. |
Date: |
Tue, 21 Jul 2009 17:58:35 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090320) |
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
- [Qemu-devel] [PATCH v3 0/5] cleanup drive handling., Gerd Hoffmann, 2009/07/16
- [Qemu-devel] [PATCH v3 2/5] add support for drive ids., Gerd Hoffmann, 2009/07/16
- [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Gerd Hoffmann, 2009/07/16
- [Qemu-devel] Re: [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Jan Kiszka, 2009/07/16
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Kevin Wolf, 2009/07/17
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Gerd Hoffmann, 2009/07/21
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options.,
Kevin Wolf <=
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Gerd Hoffmann, 2009/07/22
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Kevin Wolf, 2009/07/22
- Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options., Gerd Hoffmann, 2009/07/22
[Qemu-devel] [PATCH v3 3/5] kill drives_opt, Gerd Hoffmann, 2009/07/16
[Qemu-devel] [PATCH v3 5/5] switch -drive to QemuOpts., Gerd Hoffmann, 2009/07/16