lkml.org 
[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    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


    \
     
     \ /
      Last update: 2010-05-26 15:51    [W:4.613 / U:0.808 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site