[Top][All Lists]

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH] Use SIGIO with caution

From: Alexander Graf
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] Use SIGIO with caution
Date: Tue, 31 May 2011 17:44:13 +0200

On 31.05.2011, at 16:54, Jan Kiszka wrote:

> On 2011-05-31 16:26, Anthony Liguori wrote:
>> On 05/31/2011 09:06 AM, Jan Kiszka wrote:
>>> On 2011-05-31 15:47, Anthony Liguori wrote:
>>>> On 05/29/2011 04:50 PM, Andreas Färber wrote:
>>>>> BeOS and Haiku don't define SIGIO. When undefined, it won't arrive
>>>>> and doesn't need to be blocked.
>>>>> Signed-off-by: Andreas Färber<address@hidden>
>>>> Anything to do with signal masks is never a trivial patch BTW...
>>>> But I actually think explicit handling of SIGIO is unneeded.  I think
>>>> this is a hold over from the pre-I/O thread days where we selectively
>>>> set SIGIO on certain file descriptors to make sure that when an IO fd
>>>> became readable, we received a signal to break out of the KVM emulation
>>>> loop.
>>>> Can the folks on CC confirm/deny?
>>>> I can't see any use of SIGIO in the current source tree.
>>> At least qemu-timer.c uses SIGIO in HPET mode. That only applies to
>>> Linux hosts, though.
>> Is there any reason we still carry multiple timer implementations these 
>> days?
>> HPET shouldn't be any better than dynticks.
> On any recent kernel, for sure. BTW, the same applies to the RTC timer.

So the obvious change would be to introduce CONFIG_HPET, ifdef the SIGIO 
handling on that and also ifdef the host hpet handling code on it? That way 
it's documented well and can preferably even be turned off with 
--disable-host-hpet during configure time, which we can then slowly turn to the 


reply via email to

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