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<andreas.faer...@web.de> >>>> >>>> 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 default. Alex
