lkml.org 
[lkml]   [2011]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
    On Fri, 28 Oct 2011, Rafael J. Wysocki wrote:

    > > > Now, in the end, I think our approach makes more sense in a general
    > > > setting. The Android approach is okay for a restricted environment
    > > > where you know beforehand exactly which devices will be wakeup-capable
    > > > and which wakeup events will be monitored by userspace programs. But
    > > > for the whole range of Linux-based systems, the kernel can't rely on
    > > > such information.
    > >
    > > I think that is exactly right. The Android code is understandable written
    > > to particularly suit the Android context and may not be generally applicable.
    >
    > I'm not sure why the heck this makes any difference. For now, there doesn't
    > seem to be no one else who needs that functionality. If there were people
    > like that we'd see some concurrent approaches appearing, but for now it's only
    > us considering the alternatives _theoretically_.
    >
    > Moreover, if somebody who needs similar functionality and for whom the Android
    > stuff is not sufficient appears in the future, I don't see why not to address
    > his needs _at_ _that_ _time_ instead of trying to anticipate them (which is
    > kind of useless anyway, because we have no idea what those needs may be).

    You're missing the point. There could easily be situations where the
    Android kernel will block suspend but a more general system should
    _not_ block it. Behavior that is appropriate in an Android phone might
    not be appropriate in, say, a desktop system.

    If we duplicate the Android functionality then people (who may or may
    not theoretically want it now) might find that they _don't_ want the
    new behavior.

    > > I think the Android folk understand this and don't insist on having exactly
    > > that code merged. They just want the same functionality with the same
    > > efficiency without unnecessary change to user-space.
    >
    > The whole problem is that the Android code is proven to work on lots and
    > lots of systems and whatever else we can come up with will not be.

    But it seems likely that the Android code, which has been tested on
    only one kind of system, will _not_ work correctly on other kinds of
    systems.

    Assuming we do go ahead and merge some form of the Android code, we
    must make sure that it won't have bad effects in situations where it's
    not needed or wanted. This means more than configuring it away with
    Kconfig. When it is present, there has to be a way to control its
    behavior in some detail.

    Alan Stern



    \
     
     \ /
      Last update: 2011-10-28 17:11    [W:4.872 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site