qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] RFC: options parse in vl.c should be moduled


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH] RFC: options parse in vl.c should be moduled
Date: Fri, 30 Mar 2012 17:59:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Wanpeng Li writes:

> Consider of the options parse process in main function of vl.c is too
> long.It should be module into single function to clear ideas, strengthen
> the source code management, and increase code readability.So I module the 
> process of options parse as function options_parse, and expose some variables
> in order to not influence command-line invocations.

Another approach would be to use something similar to QOM type registration.

In order to keep code to a minimum, you can define an array of pointers to
QParameter structures, instead of an array of function pointers (what
__attribute__((constructors)) does).

So, for example:

    static void opt_icount_handler(const char *args)
    {
        if (kvm_enabled() || xen_enabled()) {
            fprintf(stderr, "-icount is not allowed with kvm or xen\n");
            exit(1);
        }
        /* ... contents of configure_icount ... */
    }

    static QEMUOption opt_icount = {
       .name = "icount",
       .signature = "[N|auto]",
       .help = "enable virtual instruction counter with 2^N clock ticks per 
instruction",
       .mode = QEMU_MODE_SYSTEM,
       .priority = QEMU_OPT_PRIO_BEFORE_DEVICES,
       .section = QEMU_OPT_SECTION_DEBUG,
       .handler = opt_icount_handler
    };
     
    param_register(opt_icount);


Here, param_register would define an array of pointers to QEMUOption structures,
although I'm not sure how this can be handled on formats other than ELF.


This is mostly what you already have in QEMUOptionParameter, and could still be
automatically generated from an extended qemu-options.hx when necessary; so I'm
talking about extending it to also contain:

* Priority; a set of predefined priorities can be provided, so that you just
  decide the partial order of your option.

* Handler function.

* QEMU mode(s) that provide this option; this could also be extended to
  establish target restrictions (e.g., only available in system-x86_64).


This might help improving the current situation by having the code where it
logically belongs (e.g., HW-specific options registered along the code for that
HW), or might just add more cruft to it...


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]