[linux-pm] [PATCH 01/13] PM: Add wake lock api.

[Woodruff, Richard]

> From: Matthew Garrett [mailto:mjg59 at srcf.ucam.org]
> Sent: Thursday, February 12, 2009 7:11 PM

> On Thu, Feb 12, 2009 at 05:42:01PM -0600, Woodruff, Richard wrote:
>
> > It is discouraging to hear comments like "we have been talking about for
> years something else" yet nothing exists or is in open development. Things can
> evolve in place.
>
> This is userlad-visible ABI. We can't evolve it in place - we need to
> get it right before merging it, otherwise we need to carry on
> maintaining code for an extended period of time in order to ensure that
> there's no userland code that depends on it.

It would be nice to do something evil and require a handshake which generates a random but unique string in sysfs at leaf level for interface. Making the namespace generation to be a bit more of a protocol instead of string matching might force a bit more flexible user space.

There are examples like syscalls of things which seem to grow with out huge contention.

> I dislike the kernel-side use of wakelocks. They're basically equivalent
> to a device returning -EBUSY during the suspend phase, which is
> something that can be done without any kernel modifications. I'm more
> interested in the userspace side, but I'd like to know more about what
> sort of constraints userspace is likely to impose. In general kernel
> people respond better to a "Here is a problem statement, here is our
> proposed solution" type statement than "Here is our code".

It is far better to get -EBUSY at the start of the suspend call out then at the end. Latency is less and not all drivers behave so well when resuming from a partial suspend.

I also agree kernel space could have been different and user space is interesting. However, I'm one to appreciate function over form. When you get them both its zen, but if is pretty and doesn't work its useless.

Thanks,
Richard W.