> > 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).
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.
Have fun,
Avery
-
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/