[lkml]   [2010]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [suspend/resume] Re: userspace notification from module
    On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
    > Dnia 2 stycznia 2010 22:01 "Rafael J. Wysocki" <> napisał(a):
    > > On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
    > > > Dnia 2 stycznia 2010 16:56 Daniel Borkmann <> napisał(a):
    > > > > Hi Andy,
    > > > >
    > > > > 2010/1/2 Andy Walls <>:
    > > > > > Why not:
    > > > > >
    > > > > > a. write a module that implements a device node that supports poll(),
    > > > > > and
    > > > > >
    > > > > > b. have a user space process select() on the fd for read or exception
    > > > > > notification
    > > > > >
    > > > > > ?
    > > > >
    > > > > This is, of course, another possible solution that is more "cleaner"
    > > > > than the one with the signals.
    > > > > Then, your userspace program would have another thread polling for the
    > > > > device node. Question is which timeout would be appropriate to be "CPU
    > > > > friendly" and to keep notification latency short?
    > > > >
    > > >
    > > > Just need as fast as possible solution and on the other hand acceptable for kernel sources.
    > > > Usually programs needs just to disconnect something or set one flag.
    > > > Even if program will have no time for this it could be enough just to send this precious info.
    > >
    > > Perhaps I don't understand correctly what you're trying to achieve, but at the
    > > moment suspend is always started from user space, this way or another, and on
    > > the majority (all?) of the modern distros pm-utils is involved in that.
    > > So, why don't you provide a pm-utils hook for your process (like, for example,
    > > NetworkManager)?
    > >
    > Thanks for Your answare.
    > Some points of my idea:
    > - don't think everyone want to use pm-utils (didn't say it is bad)

    That certainly is true, but I think these people won't have a problem setting
    up their suspend scripts to trigger the notification anyway. :-)

    Point is, suspend hooks are used anyway by almost everyone (due to graphics,
    networking, faulty drivers), so I think you could just use this mechanism, be it
    pm-utils or something else.

    To put it in a different way, you apparently want the kernel to notify the user
    space of an event originating from the user space and my question is why not
    to set up the user space to generate the notification without relying on the
    kernel to do that.

    > - this code is standard for all implementation of suspend/hibernate/resume

    I guess you mean the existing kernel-side suspend/hibernate code.

    Sure, it is, but your module is going to export the kernel's internal interface
    outside the kernel, turning it into a real API and that is a _big_ _deal_. The
    reason why it is a big deal is that while we often change the kernel's internal
    interfaces, we don't change APIs. Once created, an API (I mean a real
    userland-kernel interface) is very difficult to change, because that most often
    leads to regressions which are quite nasty from the user's point of view.

    So, basically, you want us to declare that the kernel's internal
    suspend/hibernate notification mechanism won't change in the future, which is
    not something I'm going to do at this point. Moreover, it hasn't been designed
    as an API and I don't think it's really suitable for this purpose.

    At least, that requires some more discussion, so please tell us why you need
    the kernel to notify the user space about suspend/hibernation. IOW, what's the
    final purpose of this? [Added some CCs.]

    > - it is small
    > - it have less overhead, dont need dbus and all rest services.

    That could have been a good argument if those services had not been used
    already, but that's not the case.

    > - could be even used partialy by pm-utils
    > - it is perfect just to notify about event

    OK, but why exactly do _you_ need that to happen?

    There's one important drawback of making the kernel generate the notification.
    Namely, even if your userspace task is notified by the kernel of a PM event,
    that doesn't mean it'll have the time to act upon that, because the kernel will
    attempt to freeze it right after the notification has been sent. This means
    you'd need a way to make the kernel wait for your user space process to finish
    it's job before continuing the suspend/hibernate process. Otherwise it's not
    going to be very useful.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-01-03 00:33    [W:0.025 / U:2.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site