I think it does perform acceptable behaviour however - if the drivers
(in the unlikely event) refuse the event after we've told user space,
we tell user space we resumed.
> One possible solution is for the apm driver first to _ask_
> the device drivers whether a suspend is allowed; then
> to tell the listeners; then to tell the device drivers
> to suspend.
What if the condition of the suspend gets changed by the act of paging
in memory, or some other change that occured in user space? It's a
chicken and egg problem. 8(
> Actually, it's not true that the original code sends PM_SUSPEND
> each time a listener on /dev/apm_bios replies. The code
> fragment is:
> if (as->suspends_read > 0) {
> as->suspends_read--;
> as->suspends_pending--;
> suspends_pending--;
> } else if (!send_event(APM_USER_SUSPEND))
> return -EAGAIN;
> else
> queue_event(APM_USER_SUSPEND, as);
> This only calls send_event() if the ioctl(suspend) is NOT a
> reply to a notification that was earlier read from the queue.
It is a minor point, but an unwanted one that just obfuscates the operation
of the APM system - only the first PM SUSPEND event causes a change.
Sending 'n' PM_SUSPEND events because you have 'n' listeners on
/dev/apm_bios seems to be a waste of time when it could be handled
more cleanly.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html- 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/