qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] vl: convert -m to QemuOpts


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH 2/2] vl: convert -m to QemuOpts
Date: Wed, 26 Feb 2014 14:42:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11

On 02/26/14 14:29, Paolo Bonzini wrote:
> Il 10/02/2014 18:38, Laszlo Ersek ha scritto:
>>> +    "                mem: initial amount of guest memory (default: "
>>> > +    stringify(DEFAULT_RAM_SIZE) "Mb)\n",
>> I wonder if it should rather say "MB" -- small "b" has this "bits"
>> connotation for me. But I could be wrong.
> 
> Thanks, will fix this.
> 
>> Also, again, I believe explaining the default used to mean something
>> else, but I'm OK with that part as-is.
> 
> What do you mean exactly?  I cannot parse this.

Sorry, I was ambiguous.

When you have a QemuOpt that takes an argument, then the documentation
of the default behavior usually explains the case when the QemuOpt is
present, and the argument is absent. The documentation of the default
behavior usually doesn't concern the case when the QemuOpt*s* itself is
absent. Cf.

(1) -foo bar
(2) -foo bar=baz
(3) [nothing]

The "default" in the docs tends to explain case (1), not case (3).

In this case we have: -m [mem=]megs

(1) -m mem -- makes no sense
(2) -m mem=megs -- works, and well documented
(3) [nothing] -- is what the proposed docs describe as "default", but it
doesn't match "historical practice".

(1) in general can make sense, eg. for booleans.

Anyway I don't feel strongly about this in the least -- I just thought
I'd point it out. Feel free to ignore it; I have no good suggestion as
to how to make it consistent across all options.

Thanks
Laszlo



reply via email to

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