On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler <florian@xxxxxxxxxxx> wrote: > On Sat, 5 Jun 2010 23:06:03 +0300 > Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: >> How would such stats be calculated? I presume at regular intervals you >> check which applications are holding suspend blockers and increase a >> counter. >> >> How would you do that with the dynamic PM approach? At regular >> intervals you check for which applications are running (not idle). > > IIRC, the patches discussed have debugging infrastructure in > them. The kernel does the accounting. We are not talking about debugging, we are talking about stats shown in user-space so that users can see the offending apps. It doesn't matter where the accounting is done, it would be at regular intervals and there's nothing that prevents the dynamic PM approach to offer similar stats. >> > The only difference is, that with suspend blockers, he can than >> > dismiss the applications permission to block suspend and will not miss >> > his job interview the next day because his phones battery run >> > out. And also he can use the application to a certain extent. >> >> So the difference is between removing the app, and making it run >> crappy. I don't think that's a strong argument in favor of suspend >> blockers. >> > If you think a little about it, it is. Because if the app wouldn't be > usable at all, the bug wouldn't get fixed because the user wouldn't use > it. Or not? I'm not sure what's your point here. One user not using a certain application doesn't prevent bugs to get fixed. In fact, less people using an app will cause less buzz, and less downloads, and less positive votes... which might wake up the author to think: hey, maybe I'm doing something wrong? Maybe I should really listen to those bug reports. Anyway, my point is that there's nothing special about 3rd party app stats with suspend blockers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
