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: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 14/17] Move daemonize handling to OS specific files
Date: Mon, 28 Jun 2010 15:42:09 +0000

On Mon, Jun 28, 2010 at 2:50 PM, Jes Sorensen <address@hidden> wrote:
> 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.

I think more flags should be added to arch_mask field, like
QEMU_ARCH_LINUX, QEMU_ARCH_POSIX and QEMU_ARCH_WIN32. Then the #ifdefs
should be removed. Prealloc command line flag stuff should be
conditional to CONFIG_LINUX only, there should be another check for
MAP_POPULATE where mem_preallocate is set.

Alternatively, we could have more arch_mask flags like QEMU_MAP_POPULATE.



reply via email to

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