lkml.org 
[lkml]   [2010]   [May]   [28]   [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)
    > > That's very good. But if it is done in a conceptually flawed way, some
    > > better solution should be considered for upstream merge.
    >
    > How is it flawed? Serious question.

    - It means changing drivers and quite a few apps
    - It doesn't solve the problem of rogue apps if they end up owning locks
    - It puts the deep knowledge of the platform in the applications
    - It gives the apps control of the action taken not policy indication
    - It doesn't resolve the problem of synchronization of take/releases
    stopping any suspend
    - The kernel parts are not generically useful, merely effective for
    solving a specific problem right now - even things like VM migration
    to/from phones seems to break it
    - It inverts the whole logic the kernel is following and trend it is
    following that suspend is simply a very deep idle (with implementations
    merged)

    If it was a localised turd I wouldn't worry. There are plenty df deep
    unmentionables hidden away enirely in platform specific code that deal
    with everything from stoned hardware engineers to crazed software stack
    implementations.

    Here is a question back the other way perhaps

    - If the existing kerne was almostl entirely read only, or you had to pay
    a large fee per line of code changed outside your own driver how would
    you implement the wakelock/suspend blocker API ?

    Because if you take the path that 'we want wakelockers' that is
    essentially the question you have to answer. How do you merge it so that
    nobody outside of your driver and maybe a spot of arch code knows about
    it. You are permitted a couple of sneaky substitions of core function
    bits in headers.

    Right now bits are going to leak out over the kernel which is the cause of
    friction. At the point it's invisible to everyone else they cease to be
    stakeholders so you don't have keep them happy. You've only got a couple
    in your patches but its painfully obvious from Matthew and your comments
    you'll end up needing a ton more and these will get everywhere as Android
    grows hardware platforms and CPU support as phones become more featureful
    and PC like. The moment a phone grows a USB base station with hub for
    example the entire USB stack becomes burdened with them. Matthew has
    already indicated networking needs them. Good luck with Dave Miller on
    that.

    I'm asking questions to look for generalised approaches, or even better
    doing it without new kernel stuff in the first place, but it's not the
    only way.

    Alan


    \
     
     \ /
      Last update: 2010-05-28 16:17    [W:4.200 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site