Re: [PATCH 0/8] Suspend block api (version 8)

Alan Cox
2010-05-27T19:03:13Z

> No, it's not. Forced suspend may be in response to hitting a key, but it

You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.

> may also be in response to a 30 minute timeout expiring. If I get a WoL
> packet in the 0.5 of a second between userspace deciding to suspend and
> actually doing so, the system shouldn't suspend.

I don't think that argument holds water in the form you have it

What about 5 nanoseconds before you suspend. Now you can't do that (laws
of physics and stuff).

So your position would seem to be "we have a race but can debate how big
is permissible"

The usual model is

"At no point should we be in a position when entering a suspend style
deep sleep where we neither abort the suspend, nor commit to a
suspend/resume sequence if the events we care about occur"

and that is why the hardware model is

Set wake flags
Check if idle
If idle
Suspend
else
Clear wake flags
Unwind

and the wake flags guarantee that an event at any point after the wake
flags are set until they are cleared will cause a suspend to be resumed,
possibly immediately after the suspend.

Alan