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

[Anthony Liguori]

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
> > > > > 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?

Regards,

Anthony Liguori

> Alex