Age | Commit message (Collapse) | Author |
|
Semantics of end_optional() differ subtly from the other end_FOO()
callbacks: when start_FOO() succeeds, the matching end_FOO() gets
called regardless of what happens in between. end_optional() gets
called only when everything in between succeeds as well. Entirely
undocumented, like all of the visitor API.
The only user of Visitor Callback end_optional() never did anything,
and was removed in commit 9f9ab46.
I'm about to clean up error handling in the generated visitor code,
and end_optional() is in my way. No users mean no test cases, and
making non-trivial cleanup transformations without test cases doesn't
strike me as a good idea.
Drop end_optional(), and rename start_optional() to optional(). We
can always go back to a pair of callbacks when we have an actual need.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
strtosz_suffix() might return negative error, this patch fixes
the error handling.
This patch also changes to handle error in the if statement
rather than handle success specially, this will make this use
of strtosz_suffix consistent with all other uses.
Signed-off-by: Amos Kong <akong@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Argument is null when visiting an unboxed struct. I can't see such a
visit in the current code. Fix it anyway.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Prevent mistyped command line options from incurring high memory and CPU
usage at startup. 64K elements in a range should be enough for everyone
(TM).
The OPTS_VISITOR_RANGE_MAX macro is public so that unit tests can
construct corner cases with it.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
When a well-formed range value, bounded by unsigned integers, is
encountered while processing a repeated option, enter LM_UNSIGNED_INTERVAL
and return the low bound.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Simplify the code in preparation for the next patch.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
When a well-formed range value, bounded by signed integers, is encountered
while processing a repeated option, enter LM_SIGNED_INTERVAL and return
the low bound.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
The new modes are equal-rank, exclusive alternatives of LM_IN_PROGRESS.
Teach opts_next_list(), opts_type_int() and opts_type_uint64() to handle
them.
Also enumerate explicitly what functions are valid to call in what modes:
- opts_next_list() is valid to call while flattening a range,
- opts_end_list(): ditto,
- lookup_scalar() is invalid to call during flattening; generated qapi
traversal code must continue asking for the same kind of signed/unsigned
list element until the interval is fully flattened,
- processed(): ditto.
List mode restrictions are always formulated in positive / inclusive
sense. The restrictions for lookup_scalar() and processed() are
automatically satisfied by current qapi traversals if the schema to build
is compatible with OptsVisitor.
The new list modes are not entered yet.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
We're going to need more state while processing a list of repeated
options. This change eliminates "repeated_opts_first" and adds a new state
variable:
list_mode repeated_opts repeated_opts_first
-------------- ------------- -------------------
LM_NONE NULL false
LM_STARTED non-NULL true
LM_IN_PROGRESS non-NULL false
Additionally, it is documented that lookup_scalar() and processed(), both
called by opts_type_XXX(), are invalid in LM_STARTED -- generated qapi
code calls opts_next_list() to allocate the very first link before trying
to parse a scalar into it. List mode restrictions are expressed in
positive / inclusive form.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The file is only including error.h and qerror.h. Prefer explicit
inclusion of whatever files are needed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
valgrind report:
==24534== 232 bytes in 2 blocks are definitely lost in loss record 1,245 of 1,601
==24534== at 0x4824F20: malloc (vg_replace_malloc.c:236)
==24534== by 0x293C88: malloc_and_trace (vl.c:2281)
==24534== by 0x489AD99: ??? (in /lib/libglib-2.0.so.0.2400.1)
==24534== by 0x489B23B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1)
==24534== by 0x2B4EFC: opts_visitor_new (opts-visitor.c:376)
==24534== by 0x29DEA5: net_client_init (net.c:708)
==24534== by 0x29E6C7: net_init_client (net.c:966)
==24534== by 0x2C2179: qemu_opts_foreach (qemu-option.c:1114)
==24534== by 0x29E85B: net_init_clients (net.c:1008)
==24534== by 0x296F40: main (vl.c:3463)
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
This visitor supports parsing
-option [type=]discriminator[,optarg1=val1][,optarg2=val2][,...]
style QemuOpts objects into "native" C structures. After defining the type
tree in the qapi schema (see below), a root type traversal with this
visitor linked to the underlying QemuOpts object will build the "native" C
representation of the option.
The type tree in the schema, corresponding to an option with a
discriminator, must have the following structure:
struct
scalar member for non-discriminated optarg 1 [*]
list for repeating non-discriminated optarg 2 [*]
wrapper struct
single scalar member
union
struct for discriminator case 1
scalar member for optarg 3 [*]
list for repeating optarg 4 [*]
wrapper struct
single scalar member
scalar member for optarg 5 [*]
struct for discriminator case 2
...
The "type" optarg name is fixed for the discriminator role. Its schema
representation is "union of structures", and each discriminator value must
correspond to a member name in the union.
If the option takes no "type" descriminator, then the type subtree rooted
at the union must be absent from the schema (including the union itself).
Optarg values can be of scalar types str / bool / integers / size.
Members marked with [*] may be defined as optional in the schema,
describing an optional optarg.
Repeating an optarg is supported; its schema representation must be "list
of structure with single mandatory scalar member". If an optarg is not
described as repeating in the schema (ie. it is defined as a scalar field
instead of a list), its last occurrence will take effect. Ordering between
differently named optargs is not preserved.
A mandatory list (or an optional one which is reported to be available),
corresponding to a repeating optarg, has at least one element after
successful parsing.
v1->v2:
- Update opts_type_size() prototype to uint64_t.
- Add opts_type_uint64() for options needing the full uint64_t range.
(Internals could be extracted to "cutils.c".)
- Allow negative values in opts_type_int().
- Rebase to nested Makefiles.
v2->v3:
- Factor opts_visitor_insert() out of opts_start_struct() and call it
separately for opts_root->id if there's any.
- Don't require non-negative values in opts_type_int()'s error message.
- g_malloc0() may return NULL for zero-sized requests. Support empty
structures by requesting 1 byte for them instead.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
|