Prev: [PATCH] USB: isp1362-hcd, fix double lock
Next: [PATCH] SOUND: usb/endpoint, fix dangling pointer use
From: Alan Stern on 21 Jun 2010 11:10
On Sun, 20 Jun 2010, David Brownell wrote:

> Can we put this more directly: the problem is
> that the *SYSTEM ISN'T FULLY SUSPENDED* when the
> hardware wake event triggers? (Where "*SYSTEM*
> includes userspace not just kernel. In fact the
> overall system is built from many subsystems,
> some in the kernel and some in userspace.

Indeed, the system may not even be partially suspended when the wake
event triggers.

> At the risk of being prematurely general: I'd
> point out that these subsystems probably have
> sequencing requirements. kernel-then-user is
> a degenerate case, and surely oversimplified.
> There are other examples, e.g. between kernel
> subsystems... Like needing to suspend a PMIC
> before the bus it uses, where that bus uses
> a task to manage request/response protocols.
> (Think I2C or SPI.)
>
> This is like the __init/__exit sequencing mess...
>
> In terms of userspace event delivery, I'd say
> it's a bug in the event mechanism if taking the
> next step in suspension drops any event. It
> should be queued, not lost... As a rule the
> hardware queuing works (transparently)...

There may be a misunderstanding here... People talk about events
getting lost, but what they (usually) mean is that the event isn't
actually _dropped_ -- rather, it fails to trigger a wakeup or to
prevent a suspend. When something else causes the system to resume
later on, the event will be delivered normally.

This means that the problem is not one of sequencing. The problem is
twofold:

To recognize when a wakeup event has occurred and therefore
it is not now safe to allow the system to suspend;

And to recognize when a wakeup event has been completely
handled and therefore it is once again safe to allow the system
to suspend.

> > Of course, the underlying
> > > > issue here is that the kernel has no direct way
> > to know when userspace
> > > > has finished processing an event.
>
>
> Again said more directly: there's no current
> mechanism to coordinate subsystems. Userspace
> can't communicate "I'm ready" to kernel, and
> vice versa. (a few decades ago, APM could do
> that ... we dropped such mechanisms though, and
> I'm fairly sure APM's implementation was holey.)

Yes, that's a better way of putting it. And it's not just a matter of
"userspace communicating with the kernel", because userspace is not
monolithic. There has to be a way for one user process to communicate
this information to another (I like Florian's idea). Of course, the
kernel doesn't have to worry about those details.

If one accepts a scheme in which all the suspend initiations and
cancellations are carried out by a single process (a power-manager
process), then the difficulties of communication and coordination
between the kernel and userspace are minimized.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] USB: isp1362-hcd, fix double lock
Next: [PATCH] SOUND: usb/endpoint, fix dangling pointer use