[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: Anthony Liguori
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] Use SIGIO with caution
Date: Tue, 31 May 2011 10:48:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 05/31/2011 10:44 AM, Alexander Graf wrote:

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

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

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 

Or just remove hpet and rtc.

Does anyone really object to that?


Anthony Liguori


reply via email to

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