qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 14/17] Move daemonize handling to OS specific fi


From: Jes Sorensen
Subject: Re: [Qemu-devel] [PATCH 14/17] Move daemonize handling to OS specific files
Date: Mon, 28 Jun 2010 16:50:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5

On 06/25/10 19:34, Frank Arnold wrote:
> We are doing KVM testing, so it is Linux.
> 
> What I did is putting lines like this somewhere into vl.c and
> os-posix.c:
> fprintf(stderr, "os: QEMU_OPTION_daemonize: %i", QEMU_OPTION_daemonize);
> fprintf(stderr, "vl: QEMU_OPTION_daemonize: %i", QEMU_OPTION_daemonize);
> 
> Resulting in the following output on stderr:
> os: QEMU_OPTION_daemonize: 85
> vl: QEMU_OPTION_daemonize: 86
> 
> No compile time errors. The preprocessing of qemu-options.h is done
> separately for both files. This results in a missing option definition
> for os-posix.c and discrepancy in the option enumeration.

Hi Frank,

I figured out what was causing it. qemu-options.def has an
#ifdef MAP_POPULATE in it, which isn't being set without sys/mmap.h
being included. Pretty much every other #ifdef in qemu-options.def are
based on CONFIG_foo settings or things like _WIN32 which do not change
depending on header file inclusion.

I think the easiest fix is to just add sys/mmap.h to the include list in
os-posix.c, so I just posted a patch for that. Though, in principle we
really shouldn't base qemu-options.def settings on defines pulled in
from system header files.

Cheers,
Jes



reply via email to

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