Alan, On Wed, 26 May 2010, Alan Cox wrote: > > Really, what are you getting at? Do you deny that there are programs, > > that prevent a device from sleeping? (Just think of the bouncing > > cows app) > > > > And if you have two kernels, one with which your device is dead after 1 > > hour and one with which your device is dead after 10 hours. Which would > > you prefer? I mean really... this is ridiculous. > > The problem you have is that this is policy. If I have the device wired > to a big screen and I want cows bouncing on it I'll be most upset if > instead it suspends. What you are essentially arguing for is for the > kernel to disobey the userspace. It's as ridiculous (albeit usually less > damaging) as a file system saying "Ooh thats a rude file name, the app > can't have meant it, I'll put your document soemwhere else" > > The whole API feels wrong to me. It's breaking rule #1 of technology "You > cannot solve a social problem with technology". In this case you have a > social/economic problem which is crap code. You solve it with an > economics solution - creative incentives not to produce crap code like > boxes that keep popping up saying "App XYZ is using all your battery" and > red-amber-green powermeter scores in app stores. I completely agree. We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist. In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code. Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap! That's not a solution, that's just capitulation. It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea. Thanks, tglx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
