On 31.05.2011, at 17:48, Anthony Liguori wrote: > 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<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. > > Or just remove hpet and rtc. > > Does anyone really object to that?
Do RHEL5 and SLES10 support dynticks? If yes, no objections. They're the oldest really supported distros we should possibly remotely even care about. Alex
