On Fri, Feb 13, 2009 at 4:09 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxx> 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. Which is why I offered to make it configurable. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
