qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 02/16] vl: set default ram_size during variable


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 02/16] vl: set default ram_size during variable initialization
Date: Mon, 9 Sep 2013 17:26:25 +0200

On Mon, 09 Sep 2013 16:31:03 +0200
Paolo Bonzini <address@hidden> wrote:

> Il 09/09/2013 16:06, Igor Mammedov ha scritto:
> > On Fri, 02 Aug 2013 22:33:24 +0200
> > Andreas Färber <address@hidden> wrote:
> > 
> >> Am 23.07.2013 18:22, schrieb Igor Mammedov:
> >>> Signed-off-by: Igor Mammedov <address@hidden>
> >>> ---
> >>>  vl.c |    7 +------
> >>>  1 files changed, 1 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/vl.c b/vl.c
> >>> index 8190504..bf0c658 100644
> >>> --- a/vl.c
> >>> +++ b/vl.c
> >>> @@ -2947,7 +2947,7 @@ int main(int argc, char **argv, char **envp)
> >>>      module_call_init(MODULE_INIT_MACHINE);
> >>>      machine = find_default_machine();
> >>>      cpu_model = NULL;
> >>> -    ram_size = 0;
> >>> +    ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
> >>>      snapshot = 0;
> >>>      cyls = heads = secs = 0;
> >>>      translation = BIOS_ATA_TRANSLATION_AUTO;
> >>> @@ -4064,11 +4064,6 @@ int main(int argc, char **argv, char **envp)
> >>>          exit(1);
> >>>      }
> >>>  
> >>> -    /* init the memory */
> >>> -    if (ram_size == 0) {
> >>> -        ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
> >>> -    }
> >>> -
> >>>      if (qemu_opts_foreach(qemu_find_opts("device"), device_help_func, 
> >>> NULL, 0)
> >>>          != 0) {
> >>>          exit(0);
> >>
> >> Commit message doesn't give any explanation why?
> > it was intended as cleanup
> > 
> >>
> >> What happens with -m 0? My guess is the old code translates that to the
> >> default size, where by intializing the default earlier it would stay.
> > patch is broken in this aspect. It aborts on start up with -m 0
> > 
> > The question is if -m 0 is correct value, perhaps QEMU should exit with
> > error message in this case, instead of silent fallback to default?
> 
> I guess we have to keep it for backwards compatibility.
I could swap this patch with 3/16 and add -m 0 compat logic there. Then
it would be ok to move default to initialization time + cleanup.

> 
> Paolo
> 
> 




reply via email to

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