Re: Wakeup-events implementation

[Florian Mickler <florian@mickler.org>]

On Tue, 17 Aug 2010 11:53:53 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Also, I frankly have to wonder why you demand such a large amount of
> detailed debugging about the kernel's wakeup/wakelock subsystem (as
> opposed to userspace wakelocks).  Yes, it's clear that if something
> goes wrong then you will drain your phone's battery in a few hours
> rather than a few days.  But what if something goes wrong with the VM
> subsystem, or the RF subsystem, or the keypad driver?  The device would
> crash immediately or at best become almost totally unusable.  These are
> much worse scenarios than losing some battery life -- have you added
> comparable quantities of debugging to those other parts of the kernel?
> 
> In addition, you retain all these debugging facilities in your
> production builds, not just in the debug kernels.  Doesn't this seem
> excessive?
> 

There is a theory about risk analysis and follow-up costs... i don't have
anything concrete at hand but the main idea is that if you develop for
example some monitoring for a production line of a pharmaceutical
product, you have to take into consideration all possible
failure-modes, the associated risk (likelihood * impact)
 and the likelihood of detecting these failures before shipping.

A failure mode that is fatal (->high risk), and is not detectable
before shipping is bad and a sign that you probably shouldn't produce
at all.

A failure mode that is fatal (->high risk) but is detectable in all
cases before shipping is not such a big problem. 

With battery powered devices, you have failure-modes (run-time not
optimal) that is not easily detectable before shipping. This is the
worst kind of failure-mode because you don't know if it will happen or
not. 

The risk of this failure mode (non-optimal runtime) is bad also, because
for mobile devices the runtime is critical and the fact that we talk
about millions of devices will turn this up with a non-negligible 
probability.
 
So I totally understand that the android people want all the debugging
they can get to make non-optimal runtime as visible as a broken vm or a
not functioning keypad. After all, runtime is critical for mobile
devices.

Cheers,
Flo