On Tue, 17 Aug 2010 11:53:53 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
