Re: Wakeup-events implementation

Florian Mickler
2010-08-18T07:04:04Z

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