From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIel4-0003Me-FU for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:42:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIeky-0003gc-FU for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:42:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63318) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIeky-0003gN-73 for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:42:40 -0500 Message-ID: <530DEF48.6060509@redhat.com> Date: Wed, 26 Feb 2014 14:42:32 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1391674564-3783-1-git-send-email-imammedo@redhat.com> <1391674564-3783-3-git-send-email-imammedo@redhat.com> <52F90EB3.8030902@redhat.com> <530DEC52.9030901@redhat.com> In-Reply-To: <530DEC52.9030901@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] vl: convert -m to QemuOpts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, aliguori@amazon.com, mjt@tls.msk.ru, armbru@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, lcapitulino@redhat.com, Igor Mammedov , akong@redhat.com 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