From: "Glauber Costa" <glommer@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC][PATCH 1/2] machine-specific command line switches
Date: Mon, 19 May 2008 10:18:36 -0300 [thread overview]
Message-ID: <5d6222a80805190618l59f2e312mfedd96c9ce343652@mail.gmail.com> (raw)
In-Reply-To: <482EDEF8.7030309@web.de>
On Sat, May 17, 2008 at 10:34 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> For a different project, I once wrote a patch to organize purely
> machine-specific command line switches under the hood of the respective
> machine implementations. Now the MusicPal has precisely that need as
> well. So I reanimated the patch, and here we go:
>
> The idea is to add two fields to QEMUMachine and process them:
> o options_help - a string that is inserted under a separate section of
> the "qemu -h" output.
> o parse_option - a callback invoked if a given option was not handled
> by the generic code. It returns -1 if the option is unkown, 0 if it
> is know but comes without an argument, and 1 when the argument was
> consumed.
This would be quite useful for QEMUAccel too.
So...
> +typedef int QEMUMachineParseOption(const char *optname, const char *optarg);
> +
> typedef struct QEMUMachine {
> const char *name;
> const char *desc;
> QEMUMachineInitFunc *init;
> #define RAMSIZE_FIXED (1 << 0)
> ram_addr_t ram_require;
> + const char *options_help;
> + QEMUMachineParseOption *parse_option;
> struct QEMUMachine *next;
> } QEMUMachine;
Why don't turn the naming into a more generic one? Maybe QEMUOpts, or
smth like this.
> Index: b/vl.c
> ===================================================================
> --- a/vl.c
> +++ b/vl.c
> @@ -7141,6 +7141,8 @@ static int main_loop(void)
>
> static void help(int exitcode)
> {
> + QEMUMachine *m;
> +
> printf("QEMU PC emulator version " QEMU_VERSION ", Copyright (c) 2003-2008 Fabrice Bellard\n"
> "usage: %s [options] [disk_image]\n"
> "\n"
> @@ -7275,14 +7277,7 @@ static void help(int exitcode)
> "-clock force the use of the given methods for timer alarm.\n"
> " To see what timers are available use -clock ?\n"
> "-startdate select initial date of the clock\n"
> - "\n"
> - "During emulation, the following keys are useful:\n"
> - "ctrl-alt-f toggle full screen\n"
> - "ctrl-alt-n switch to virtual console 'n'\n"
> - "ctrl-alt toggle mouse and keyboard grab\n"
> - "\n"
> - "When using -nographic, press 'ctrl-a h' to get some help.\n"
> - ,
> + "\n",
> "qemu",
> DEFAULT_RAM_SIZE,
> #ifndef _WIN32
> @@ -7291,6 +7286,17 @@ static void help(int exitcode)
> #endif
> DEFAULT_GDBSTUB_PORT,
> "/tmp/qemu.log");
> + for (m = first_machine; m != NULL; m = m->next) {
> + if (m->options_help)
> + printf("Options specific to %s machine:\n%s\n",
> + m->name, m->options_help);
> + }
So, If I understand correctly what you mean here, This will print out
specific options for every registered machine, right?
It does not sound correct, since we won't have support for more than
one in the same binary anyway. It looks correct, tough, if we think
that we're not representing 'machines', but anything dumping specific
options here. But in this case, wouldn't it be better to leave the
whole help string
to the user of the interface, instead of just using m->name and m->help?
> @@ -7673,7 +7679,7 @@ int main(int argc, char **argv)
> const char *gdbstub_port;
> #endif
> uint32_t boot_devices_bitmap = 0;
> - int i;
> + int i, result;
> int snapshot, linux_boot, net_boot;
> const char *initrd_filename;
> const char *kernel_filename, *kernel_cmdline;
> @@ -7692,7 +7698,7 @@ int main(int argc, char **argv)
> const char *parallel_devices[MAX_PARALLEL_PORTS];
> int parallel_device_index;
> const char *loadvm = NULL;
> - QEMUMachine *machine;
> + QEMUMachine *machine, *m;
> const char *cpu_model;
> const char *usb_devices[MAX_USB_CMDLINE];
> int usb_devices_index;
> @@ -7784,6 +7790,21 @@ int main(int argc, char **argv)
> /* Treat --foo the same as -foo. */
> if (r[1] == '-')
> r++;
> +
> + result = -1;
> + for (m = first_machine; m != NULL; m = m->next) {
> + if (m->parse_option) {
I don't like this very much. There's no point in having specific
options without this parse_option anyway. So it would be better to
check for it before displaying the options at all, and simplify the
code here.
> + result = m->parse_option(r,
> + (optind < argc) ? argv[optind] : NULL);
> + if (result >= 0)
> + break;
> + }
> + }
> + if (result >= 0) {
> + optind += result;
> + continue;
> + }
> +
Other than the commented, it all looks very good.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
next prev parent reply other threads:[~2008-05-19 13:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-17 13:34 [Qemu-devel] [RFC][PATCH 1/2] machine-specific command line switches Jan Kiszka
2008-05-19 13:18 ` Glauber Costa [this message]
2008-05-19 13:53 ` [Qemu-devel] " Jan Kiszka
2008-05-19 14:02 ` Glauber Costa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d6222a80805190618l59f2e312mfedd96c9ce343652@mail.gmail.com \
--to=glommer@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).