From: "Glauber Costa" <glommer@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/3] Modular command line options
Date: Wed, 21 May 2008 16:17:48 -0300 [thread overview]
Message-ID: <5d6222a80805211217w7c9de193g33ebbae74db81629@mail.gmail.com> (raw)
In-Reply-To: <48336413.2060909@web.de>
Looks awesome.
But if you allow me to be a bit boring again, I have some extra comments.
>
> +#define HAS_ARG 0x0001
> +
> +typedef struct QEMUOption {
> + const char *name;
> + int flags;
> + int index;
> +} QEMUOption;
> +
> +typedef void QEMUOptionParser(int index, const char *optarg);
> +
> +typedef struct QEMUOptionSet {
> + const QEMUOption *options;
> + const char *help_string;
> + QEMUOptionParser *parse_handler;
> + struct QEMUOptionSet *next;
> +} QEMUOptionSet;
This is a bit counter-intuitive. If we switch to this model, the Help
string would be better with the option itself, rather than the option
set. Listing the options would then be a matter of iterating over each
option,
and then printing each of them. An optional help string in the option
set could be used as a header. Like this:
Help string for the option set:
-foo help for foo option, in a QEMUoption
-bar help for bar option, in a QEMUOption
This seems cleaner and more flexible to me. What do you think?
> #ifdef TARGET_PPC
> -#define DEFAULT_RAM_SIZE 144
> +#define DEFAULT_RAM_SIZE 144
> +#define DEFAULT_RAM_SIZE_STR "144"
> #else
> -#define DEFAULT_RAM_SIZE 128
> +#define DEFAULT_RAM_SIZE 128
> +#define DEFAULT_RAM_SIZE_STR "128"
> #endif
This is a bit ugly IMHO.
Defining:
__STR(x) #x
STR(x) __STR(x) in a common header sounds better. We can then just
STR(DEFAULT_RAM_SIZE), or whatever, in any string pasting.
Since we're moving to this scheme, it is possible that new needs for
doing the same thing will arise, and then just coming up with a bunch
of FOO , FOO_STR binoms seems not elegant enough.
> +static int snapshot;
> -static int drive_init(struct drive_opt *arg, int snapshot,
> +static int drive_init(struct drive_opt *arg, int use_snapshot,
> QEMUMachine *machine)
static global variable, static function. Can't we just not use the
argument at all? Yeah, I know it was there before, but...
> +
> +#ifdef CONFIG_GUS
> + {
> + "gus",
> + "Gravis Ultrasound GF1",
> + 0,
> + 1,
> + { .init_isa = GUS_init }
> + },
> #endif
For options that are dependant on specific defines, it is better to
make them separate, and then register the option set conditionally.
But yeah, I know you're not doing everything in this patch.
Just wanted to leave the opinion, and see whether or not you agree with it.
Other than that, seems all beautiful.
--
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-21 19:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 23:51 [Qemu-devel] [PATCH 1/3] Modular command line options Jan Kiszka
2008-05-21 19:17 ` Glauber Costa [this message]
2008-05-21 20:58 ` Fabrice Bellard
2008-05-22 10:11 ` Ian Jackson
2008-05-22 10:19 ` Ian Jackson
2008-05-22 10:20 ` Ian Jackson
2008-05-22 12:49 ` [Qemu-devel] " Jan Kiszka
2008-05-23 13:29 ` Glauber Costa
2008-05-23 15:12 ` Jan Kiszka
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=5d6222a80805211217w7c9de193g33ebbae74db81629@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).