qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [RFC v4] Introduce qemu_madvise()


From: Blue Swirl
Subject: [Qemu-devel] Re: [RFC v4] Introduce qemu_madvise()
Date: Tue, 14 Sep 2010 17:10:48 +0000

On Tue, Sep 14, 2010 at 4:34 PM, Alexander Graf <address@hidden> wrote:
>
> Am 14.09.2010 um 18:31 schrieb Blue Swirl <address@hidden>:
>
>> On Mon, Sep 13, 2010 at 9:26 PM, Andreas Färber <address@hidden> wrote:
>>> From: Andreas Färber <address@hidden>
>>>
>>> vl.c has a Sun-specific hack to supply a prototype for madvise(),
>>> but the call site has apparently moved to arch_init.c.
>>>
>>> Haiku doesn't implement madvise() in favor of posix_madvise().
>>> OpenBSD and Solaris 10 don't implement posix_madvise() but madvise().
>>>
>>> Check for madvise() and posix_madvise() in configure and supply 
>>> qemu_madvise()
>>> as wrapper. Prefer madvise() over posix_madvise() due to flag availability.
>>> Convert all callers to use qemu_madvise() and QEMU_MADV_*.
>>>
>>> Note that on Solaris the warning is fixed by moving the madvise() prototype,
>>> not by qemu_madvise() itself. It will help with future porting though.
>>>
>>> v3 -> v4:
>>> * Eliminate #ifdefs at qemu_advise() call sites. Requested by Blue Swirl.
>>>  This will currently break the check in kvm-all.c by calling madvise() with
>>>  a supported flag, which will not fail. Ideas/patches welcome.
>>
>> Your original switch with synthetic (1<<0, 1<<1 etc) values for
>> QEMU_MADV_* for all hosts (never reusing MADV_* defines).
>
> Ugh. Back to square one? How about
>
> #define QEMU_MADV_INVALID -1
>
> Then you can define unknown balues against that. Should never occur otherwise.

Yeah, then the generic code could check for QEMU_MADV_INVALID. That's
simpler than the switch.



reply via email to

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