Re: [PATCH 09/10] Input: Hold wake lock while event queue is not empty.

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Fri, Feb 13, 2009 at 03:51:40PM -0800, Arve Hjønnevåg wrote:
> On Thu, Feb 12, 2009 at 4:57 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > It's not the job of the kernel to guard against userspace doing foolish
> > things.
> 
> Not true. The kernel in general tries to protect processes from
> causing harm to other processes or to the kernel itself.

Harm, yes. This isn't harm. It's undesirable, in the same way that an 
application taking a wake lock and then spinning until your battery runs 
out is undesirable. It's not the kernel's job to prevent that.

> > Either you want to wait for input events to be consumed before
> > suspend or you don't - arbitrary timeouts provide no guarantees about
> > the correctness of your platform's behaviour. The default permissions on
> > the event devices mean that the only components that could interfere
> > with this are ones under your control, so fixing them seems like the
> > sensible approach.
> 
> We did fix the bug. My point is that is it completely unreasonable for
> the user space to code take more than 5 seconds to read an input
> event. Trying to protecting the system (not the app) against this is
> not unreasonable.

Completely unreasoable *in your use case*. The kernel doesn't exist to 
satisfy only your use case - it has to satisfy as many as possible. 
That's why hardcoding policy decisions such as this timeout is a bad 
idea.

-- 
Matthew Garrett | mjg59@srcf.ucam.org