> On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote:
>
> > > willing to exercise this power. We would not break compatibility with
> > > any std kernel by instead having a apmd send a "reject all" ioctl
> > > instead, and so deal with events without having the pressure of having
> > > to reject or accept them, and let us remove all the veto code from the
> > > kernel driver. Or am I missing something?
> >
> > That sounds workable. But the same program could reply to the events just
> > as well as issue the ioctl 8)
>
> AFAICT some APM BIOSes get impatient if you don't acknowledge/reject
> the requests fast enough, and start to go bananas. By always
> rejecting requests and then making user requests instead at some
> time later, we might eliminate this problem (or just cause new
> ones).
Indeed. Neither proposal has however received wide testing as far as I
know. The userspace ACCEPT/REJECT method was available as a patch from
Stephen for a while though.
> Also, I don't think the "critical suspend" message can be rejected
> at all, so it would have to be a special case where currently I
> don't think it's too bad.
ATM it is a "special case" - we print a message if we try to reject a
critical suspend. However the case is not so special that it requires
more than a line or two ;-)
I don't think there is any cause for concern on that front.
[...]
--http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/