[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: |
Wed, 22 Jul 2009 09:31:12 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090320) |
Gerd Hoffmann schrieb:
> On 07/21/09 17:58, Kevin Wolf wrote:
>> 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.
>
> -net is a very special beast as the list of parameters is very different
> for -net nic, -net tap, -net user, ...
>
> So it probably makes sense to have a separate QemuOptsList for each of
> them instead of storing a "type=[nic|tap|user]" into a common net list.
I agree, -net should be done different, so this was a bad example. But I
thought we had more of them. -boot is an option with implicit first
parameter name, and there was at least a discussion on making -smp
another one. There might be more.
Or do you want to keep the old parsing code for these options?
>>> 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.
>
> Yep, so we have one place where we catch parse errors instead of having
> each callsite to check for qemu_opt_get_$type() failures.
Sounds great. Now it just needs to be implemented. ;-)
Kevin
- [Qemu-devel] [PATCH v3 2/5] add support for drive ids., (continued)
- [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, 2009/07/21
- 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 <=
- 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
[Qemu-devel] [PATCH v3 1/5] kill drives_table, Gerd Hoffmann, 2009/07/16