Re: [suspend/resume] Re: userspace notification from module

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
> 
> Dnia 2 stycznia 2010 22:01 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> 
> > On Saturday 02 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 2 stycznia 2010 16:56 	Daniel Borkmann <danborkmann@googlemail.com> napisał(a):
> > > > Hi Andy,
> > > > 
> > > > 2010/1/2 Andy Walls <awalls@radix.net>:
> > > > > 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.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 3 stycznia 2010 0:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > 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. :-)
> 

But it means almoust always create dbus interface and send message by script.
For what? only to know if system going resume or suspend?

> 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.

Because now kernel know better what is going on.

> 
> > - 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.

Abosulutly no!
It's so primitive module and even with different api it could be easy to adept.
Next if it can't be in kernel source tree for someone could be very usefull.

This module could only sends bool/ioctl - system resumed.

> 
> 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.]

Yes, it is only first step.
Have created different point of view, not all linux boxes are desktops/laptops.
What about embedeed solutions?
Why app must implement all other to know about resume/suspend?
Why not open file and know this easily?

> 
> > - 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.

Yes it is.
For every other case it was pm-utils created.

> 
> > - 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.
> 

First of all i want to start discussion about this topic and looks like started :)

So what was in my mind? There are lots of small devices today with linux.
Lots of them has got unstandardized suspend/resume detection.
It could be too much info exposed from kernel by this module/propose i understand
for program info about pm_post_resume event could be anought.

We have now 3types of suspend implementation and 1 kernel API inside.
App typicaly need just 2-3 event types - suspending, resumming, idle.
I dont want to slow down kernel suspend, block or something, just perform 
some actions in apps - typicaly try to reconnect.
It could be new kernel standard to easy adept some actions.

Why not pm-utils connect to such module and gather data?
Then It could work as hal service.
But hook on kernel like /sbin/init but for suspend and resume, looks like other solution.
IOW sending event to kernel to perform action and launch userspace once 
more just before pm-event chain ... check return_val, sounds like other 
solution/ other kind of module.

What about this discusion:
http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html

I will perform some tests to know what amount of time is usualy needed to disconnect
nicely client or something.

Next what about fuse filesystems, there are some network based.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Daniel Borkmann]

[-- Attachment #1.1: Type: text/plain, Size: 2272 bytes --]

Bartłomiej Zimoń wrote:
> Dnia 3 stycznia 2010 0:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
>>> 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. :-)
>>
> 
> But it means almoust always create dbus interface and send message by script.
> For what? only to know if system going resume or suspend?

Hmm.. dbus looks like a bit too much overhead for me, just to bring this
information to your process, there should be an easier way to do this.

> Abosulutly no!
> It's so primitive module and even with different api it could be easy to adept.
> Next if it can't be in kernel source tree for someone could be very usefull.
> 
> This module could only sends bool/ioctl - system resumed.
> 
>> 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.]
> 
> Yes, it is only first step.
> Have created different point of view, not all linux boxes are desktops/laptops.
> What about embedeed solutions?
> Why app must implement all other to know about resume/suspend?
> Why not open file and know this easily?

I actually don't like the idea to put such information into a file
either. Anyways, if you'd have a thread polling for these file contents,
I think a thread that does netlink comunication (from the userspace
side) would be the better soultion. Then, your module takes care to
broadcast the message to the registered clients.

Have a look at:

http://www.linuxjournal.com/article/7356

> What about this discusion:
> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html
> 
> I will perform some tests to know what amount of time is usualy needed to disconnect
> nicely client or something.

Actually I think this is what signals are there for and bringing this
information via signals would have least overhead, problem is that this
is not POSIX compliant, but may be you could have a try at this?!

Regards,
Daniel


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [suspend/resume] Re: userspace notification from module

[Daniel Borkmann]

[-- Attachment #1.1: Type: text/plain, Size: 1300 bytes --]

Daniel Borkmann wrote:
> Bartłomiej Zimoń wrote:
>> What about this discusion:
>> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html
>>
>> I will perform some tests to know what amount of time is usualy needed to disconnect
>> nicely client or something.
> 
> Actually I think this is what signals are there for and bringing this
> information via signals would have least overhead, problem is that this
> is not POSIX compliant, but may be you could have a try at this?!

I'm not quite sure how this is implemented within the kernel, but if you
have lots of processes doing their suspend routines, I think it is not
guaranteed that all of this finishes before doing the suspend, so you
will have some unknown states, processes could stuck at (and later [at
some unintended point of time] resume on).
Or, on the other hand you will have to block the kernel notification
chain until all the procs have signaled that they're done doing their
jobs. Regarding this, the kernel suspend would depend on the correctness
/ termination of userspace routines which is a _very_ bad thing.
You will have to introducte some timeouts... see where this is going? I
think a file interface might be too simple... just some thoughts about this.

Regards,
Daniel


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 3 stycznia 2010 11:06 	Daniel Borkmann <danborkmann@googlemail.com> napisał(a):
> Daniel Borkmann wrote:
> > Bartłomiej Zimoń wrote:
> >> What about this discusion:
> >> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html
> >>
> >> I will perform some tests to know what amount of time is usualy needed to disconnect
> >> nicely client or something.
> > 
> > Actually I think this is what signals are there for and bringing this
> > information via signals would have least overhead, problem is that this
> > is not POSIX compliant, but may be you could have a try at this?!
> 
> I'm not quite sure how this is implemented within the kernel, but if you
> have lots of processes doing their suspend routines, I think it is not
> guaranteed that all of this finishes before doing the suspend, so you
> will have some unknown states, processes could stuck at (and later [at
> some unintended point of time] resume on).
> Or, on the other hand you will have to block the kernel notification
> chain until all the procs have signaled that they're done doing their
> jobs. Regarding this, the kernel suspend would depend on the correctness
> / termination of userspace routines which is a _very_ bad thing.
> You will have to introducte some timeouts... see where this is going? I
> think a file interface might be too simple... just some thoughts about this.
> 

mhm, why not to create kernel based pm event messaging for processes?
How it is implemented on other platforms?
Because on MacOsX looks like program registers callback for such event.

I dont know if every pm_notifier blocks suspend until return from callback.

If we cant do it simple we can do it better.
Rafael what do You think about it?

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> Dnia 3 stycznia 2010 11:06 	Daniel Borkmann <danborkmann@googlemail.com> napisał(a):
> > Daniel Borkmann wrote:
> > > Bartłomiej Zimoń wrote:
> > >> What about this discusion:
> > >> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html
> > >>
> > >> I will perform some tests to know what amount of time is usualy needed to disconnect
> > >> nicely client or something.
> > > 
> > > Actually I think this is what signals are there for and bringing this
> > > information via signals would have least overhead, problem is that this
> > > is not POSIX compliant, but may be you could have a try at this?!
> > 
> > I'm not quite sure how this is implemented within the kernel, but if you
> > have lots of processes doing their suspend routines, I think it is not
> > guaranteed that all of this finishes before doing the suspend, so you
> > will have some unknown states, processes could stuck at (and later [at
> > some unintended point of time] resume on).
> > Or, on the other hand you will have to block the kernel notification
> > chain until all the procs have signaled that they're done doing their
> > jobs. Regarding this, the kernel suspend would depend on the correctness
> > / termination of userspace routines which is a _very_ bad thing.
> > You will have to introducte some timeouts... see where this is going? I
> > think a file interface might be too simple... just some thoughts about this.
> > 
> 
> mhm, why not to create kernel based pm event messaging for processes?
> How it is implemented on other platforms?
> Because on MacOsX looks like program registers callback for such event.
> 
> I dont know if every pm_notifier blocks suspend until return from callback.
> 
> If we cant do it simple we can do it better.
> Rafael what do You think about it?

I've just said, roughly, in a message I sent to you a while back.

You need a power manager, but not necessarily in the kernel.  The role of the
power manager would be to:
(1) pass suspend requests from different sources in the user space (a GUI for
    one example) to the kernel,
(2) notify processes which registered for that when it's going to pass a
    suspend (or hibernate) request to the kernel,
(3) wait for the notified processes to complete the pre-suspend preparations
    they require.

There are a few more things to consider here.  For example, what if one of the
registered processes becomes unresponsive?  Are we going to suspend anyway
or notify the user and wait for him to resolve the problem?  In the latter
case, what to do if that is, for example, an emergency hibernation started
because we're running out of battery power?  Etc.

Some time ago openSUSE had a daemon called powersaved used for this purpose,
but then it was replaced by pm-utils, apparently because everybody else was
using pm-utils and it just wasn't worth maintaining a different solution for
one distro only.  Maybe it's time to rethink this idea?

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Stefan Seyfried]

Hi,

On Sun, 3 Jan 2010 22:49:11 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> > mhm, why not to create kernel based pm event messaging for processes?

I don't think you need the kernel for that.

> > How it is implemented on other platforms?
> > Because on MacOsX looks like program registers callback for such event.
> > 
> > I dont know if every pm_notifier blocks suspend until return from callback.
> > 
> > If we cant do it simple we can do it better.
> > Rafael what do You think about it?

Basically, modern desktops do it exactly this way. They have one "power
manager" (be it gnome-power-manager or KDE's solid) and the
applications are notified by it if a suspend is going to happen.

E.g. the power manager will tell the volume manager (the thing that
mounted the USB stick) "we will suspend, please unmount everything".
Other desktop components will also be notified.

Some processes might also wish to inhibit the suspend (e.g. a CD
burning application while it is burning).

The power manager is the "single point of decision". It might decide to
ignore the CD burning application, if the power is critically low
(better a ruined CD than data loss by hard poweroff), but honor it
otherwise. It might decide to ask the user (and it has an easy way to
do so, since it is running in the users session and thus has access to
the X display), but proceed after a timeout etc...

All this is already possible and does not need any kernel changes at
all.

> I've just said, roughly, in a message I sent to you a while back.
> 
> You need a power manager, but not necessarily in the kernel.  The role of the
> power manager would be to:
> (1) pass suspend requests from different sources in the user space (a GUI for
>     one example) to the kernel,
> (2) notify processes which registered for that when it's going to pass a
>     suspend (or hibernate) request to the kernel,
> (3) wait for the notified processes to complete the pre-suspend preparations
>     they require.

Exactly.

> There are a few more things to consider here.  For example, what if one of the
> registered processes becomes unresponsive?  Are we going to suspend anyway
> or notify the user and wait for him to resolve the problem?  In the latter
> case, what to do if that is, for example, an emergency hibernation started
> because we're running out of battery power?  Etc.
> 
> Some time ago openSUSE had a daemon called powersaved used for this purpose,
> but then it was replaced by pm-utils, apparently because everybody else was
> using pm-utils and it just wasn't worth maintaining a different solution for
> one distro only.  Maybe it's time to rethink this idea?

No. Because what powersaved did was not fundamentally different from
what gnome-power-manager / pm-utils does now. The difference was, that
it was a daemon running as root. Which brought a few problems of its
own:
 * communication with the user was not easily possible
 * it mixed up policy and mechanism (powersaved decided what to do if
   you press the power or sleep button, and you needed root to configure
   that behaviour).

And before somebody comes along with arguments like "but what about my
manually mounted NFS share - who will unmount that?", I can only tell
you: "go away". There is no way to imlement a sane solution that will
take care of all the crazy manual configurations people can dream of,
so you can only tell them "you mounted it manually - so unmount it
manually".

And you can give them pm-utils hooks that give them a mechanism to do
their manual stuff semi-automatically during suspend / resume.

Have fun :-)

	seife
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, Daniel Borkmann wrote:
...
> Actually I think this is what signals are there for and bringing this
> information via signals would have least overhead, problem is that this
> is not POSIX compliant, but may be you could have a try at this?!

You need information to be passed both ways.

Namely, a power manager (be it a kernel module or a user space process) has
to communicate to the (other) processes that it's about to suspend and it
should wait for each of them to say that it's now OK to suspend.

You could do that with signals, but I guess it's not the easiest way. :-)

Rafael

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> Dnia 3 stycznia 2010 0:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > > 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. :-)
> > 
> 
> But it means almoust always create dbus interface and send message by script.

Of course you don't need to do that.  For example, you can use a UNIX domain
socket for sending the notification from one user space process (a power
manager) to another one (application wanting to be notified) and the
confirmation that's safe to suspend the other way around.  Generally, arbitrary
message-passing interface between two processes would be fine IMO.

...
> > 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.
> 
> Because now kernel know better what is going on.

That's because it's just been told by the user space about that.

Basically, you want something like this to happen:

process A ->(suspend) kernel
kernel ->(suspending) process B

where the kernel won't wait for process B to do whatever it has to do before
suspending.  In my opinion it'd be better to do something like this

process A ->(suspending) process B
process B ->(ack) process A
process A ->(suspend) kernel

... 
> > 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.]
> 
> Yes, it is only first step.
> Have created different point of view, not all linux boxes are desktops/laptops.
> What about embedeed solutions?
> Why app must implement all other to know about resume/suspend?
> Why not open file and know this easily?

And why not to open a socket?

Really, what I think you want is a standard way of notifying applications that
suspend or hibernation is going to happen, but you don't need the kernel to
take part in that directly.

Putting things into the kernel is not the only way to avoid overheads IMO.

... 
> First of all i want to start discussion about this topic and looks like started :)
> 
> So what was in my mind? There are lots of small devices today with linux.
> Lots of them has got unstandardized suspend/resume detection.

OK, so we need a standard here.  I can't agree more.  However, does that mean
the kernel has to be directly involved in that?  If it does, then why exactly?

> It could be too much info exposed from kernel by this module/propose i understand
> for program info about pm_post_resume event could be anought.
> 
> We have now 3types of suspend implementation and 1 kernel API inside.
> App typicaly need just 2-3 event types - suspending, resumming, idle.
> I dont want to slow down kernel suspend, block or something, just perform 
> some actions in apps - typicaly try to reconnect.
> It could be new kernel standard to easy adept some actions.
> 
> Why not pm-utils connect to such module and gather data?
> Then It could work as hal service.
> But hook on kernel like /sbin/init but for suspend and resume, looks like other solution.
> IOW sending event to kernel to perform action and launch userspace once 
> more just before pm-event chain ... check return_val, sounds like other 
> solution/ other kind of module.

Again, you don't need a kernel module for that.  Moreover, using a kernel
module for that is actually inconvenient.

> What about this discusion:
> http://lists.freedesktop.org/archives/devkit-devel/2009-December/000617.html

Well, it would be nice if the desktop people sent CCs of such discussions to
linux-pm.  Talking about the kernel without involving people who actually work
on it is not exactly productive IMO.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > > 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.
> > 
> > Because now kernel know better what is going on.
> 
> That's because it's just been told by the user space about that.
> 
> Basically, you want something like this to happen:
> 
> process A ->(suspend) kernel
> kernel ->(suspending) process B
> 

Yes.

> where the kernel won't wait for process B to do whatever it has to do before
> suspending.  In my opinion it'd be better to do something like this
> 
> process A ->(suspending) process B
> process B ->(ack) process A
> process A ->(suspend) kernel
> 
> ... 

Please forget for a moment about pm-utils.

I was thinking about sf like this:
pm-notify is registered in pm_notifier_chain or called before pm_notifiers_chain
pm-notify -> (suspending) all registerd processes
some processes ->(ack) pm-notify
after timeout ( 1s. could be ok) pm-notify will send NOTIFY_OK and kernel will cont. suspending

It could be even UIO module but there are no pm events reachable there?

If it is not clean, we must extend pm-utils or write something new
(with backends dbus, ipc, scripts, ...)
But You see? We still have no information from kernel about events 
(especialy resume) or maybe i dont see this ;/

Thanks for your understanding Rafael :)

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
...
> 
> It could be even UIO module but there are no pm events reachable there?
> 
> If it is not clean, we must extend pm-utils or write something new
> (with backends dbus, ipc, scripts, ...)
> But You see? We still have no information from kernel about events 
> (especialy resume) or maybe i dont see this ;/

They are available to the process that tells the kernel to suspend.

Namely, to tell the kernel to suspend to RAM, the process (call it a power
manager) needs to (for example) fprintf() "mem" to /sys/power/state.  As soon
as this happens, the kernel will start to freeze processes (except for the
power manager itself), so the power manager knows that everything should be
ready for the suspend before it writes to /sys/power/state.  It doesn't need
the kernel to tell it when the suspend is going to start, because it _knows_
that in advance.

Now, the fprintf() used to trigger the suspend will not return until the resume
is complete.  So, again, when the fprintf() returns, the power manager will know
that the resume has just finished (more precisely, the kernel side of it has
just finished).

There simply is no need for any special communication between the kernel and
the power manager.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 4 stycznia 2010 0:30 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):

> On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> > Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> ...
> > 
> > It could be even UIO module but there are no pm events reachable there?
> > 
> > If it is not clean, we must extend pm-utils or write something new
> > (with backends dbus, ipc, scripts, ...)
> > But You see? We still have no information from kernel about events 
> > (especialy resume) or maybe i dont see this ;/
> 
> They are available to the process that tells the kernel to suspend.
> 
> Namely, to tell the kernel to suspend to RAM, the process (call it a power
> manager) needs to (for example) fprintf() "mem" to /sys/power/state.  As soon
> as this happens, the kernel will start to freeze processes (except for the
> power manager itself), so the power manager knows that everything should be
> ready for the suspend before it writes to /sys/power/state.  It doesn't need
> the kernel to tell it when the suspend is going to start, because it _knows_
> that in advance.
> 
> Now, the fprintf() used to trigger the suspend will not return until the resume
> is complete.  So, again, when the fprintf() returns, the power manager will know
> that the resume has just finished (more precisely, the kernel side of it has
> just finished).
> 
> There simply is no need for any special communication between the kernel and
> the power manager.
> 

Thx Rafael - now it clear to me.
And what do You think about sending extra signals to processes?

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> Dnia 4 stycznia 2010 0:30 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> 
> > On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > ...
> > > 
> > > It could be even UIO module but there are no pm events reachable there?
> > > 
> > > If it is not clean, we must extend pm-utils or write something new
> > > (with backends dbus, ipc, scripts, ...)
> > > But You see? We still have no information from kernel about events 
> > > (especialy resume) or maybe i dont see this ;/
> > 
> > They are available to the process that tells the kernel to suspend.
> > 
> > Namely, to tell the kernel to suspend to RAM, the process (call it a power
> > manager) needs to (for example) fprintf() "mem" to /sys/power/state.  As soon
> > as this happens, the kernel will start to freeze processes (except for the
> > power manager itself), so the power manager knows that everything should be
> > ready for the suspend before it writes to /sys/power/state.  It doesn't need
> > the kernel to tell it when the suspend is going to start, because it _knows_
> > that in advance.
> > 
> > Now, the fprintf() used to trigger the suspend will not return until the resume
> > is complete.  So, again, when the fprintf() returns, the power manager will know
> > that the resume has just finished (more precisely, the kernel side of it has
> > just finished).
> > 
> > There simply is no need for any special communication between the kernel and
> > the power manager.
> > 
> 
> Thx Rafael - now it clear to me.
> And what do You think about sending extra signals to processes?

I don't see a problem with this in principle, although I don't think signals
are very suitable for this particular purpose, because you need two-way
communication between the power manager and the processes it's going to
notify (because it has to wait for the processes to finish their preparations
and to tell it that they are ready).

For this purpose it's better to have a file descriptor you can block on (like a
socket or a pipe) while the other side is doing it's job.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 4 stycznia 2010 0:45 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> > Thx Rafael - now it clear to me.
> > And what do You think about sending extra signals to processes?
> 
> I don't see a problem with this in principle, although I don't think signals
> are very suitable for this particular purpose, because you need two-way
> communication between the power manager and the processes it's going to
> notify (because it has to wait for the processes to finish their preparations
> and to tell it that they are ready).
> 
> For this purpose it's better to have a file descriptor you can block on (like a
> socket or a pipe) while the other side is doing it's job.
> 

So let's create one in power/user.c or use /sys/power/state for this :)

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Daniel Borkmann]

[-- Attachment #1.1: Type: text/plain, Size: 1160 bytes --]

Rafael J. Wysocki wrote:
> On Monday 04 January 2010, Bartłomiej Zimoń wrote:
>> And what do You think about sending extra signals to processes?
> 
> I don't see a problem with this in principle, although I don't think signals
> are very suitable for this particular purpose, because you need two-way
> communication between the power manager and the processes it's going to
> notify (because it has to wait for the processes to finish their preparations
> and to tell it that they are ready).

Again, just to abandon some thoughts... do you really need that "two-way
communication"? I mean if the kernel delivers that specific signal to
the process/task_struct [do_signal():handle_signal()] it has to save the
original execution context that will later on be restored after the
non-default signal handling function returns. This is our ACK /
notification for the successful return of the programs "suspend
handler". The kernel module (if such exists) could be notified about
that for instance by a simple notifier hook within kernelspace. I mean
if I see this right, the "two-way" is just for the ACK isn't it?

Best regards,
Daniel


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> Dnia 4 stycznia 2010 0:45 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> > > Thx Rafael - now it clear to me.
> > > And what do You think about sending extra signals to processes?
> > 
> > I don't see a problem with this in principle, although I don't think signals
> > are very suitable for this particular purpose, because you need two-way
> > communication between the power manager and the processes it's going to
> > notify (because it has to wait for the processes to finish their preparations
> > and to tell it that they are ready).
> > 
> > For this purpose it's better to have a file descriptor you can block on (like a
> > socket or a pipe) while the other side is doing it's job.
> > 
> 
> So let's create one in power/user.c or use /sys/power/state for this :)

I don't see a good reason, really.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Anders Eriksson]

rjw@sisk.pl said:
>> > I don't see a problem with this in principle, although I don't think signals
>> > are very suitable for this particular purpose, because you need two-way
>> > communication between the power manager and the processes it's going to
>> > notify (because it has to wait for the processes to finish their preparations
>> > and to tell it that they are ready). 

Wouldn't there need to be dependecy tracking for the userspace processes? A 
process couldn't signal "done" until it know there's no more work to do, which 
requires all other processes to finish up first.

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> 
> rjw@sisk.pl said:
> >> > I don't see a problem with this in principle, although I don't think signals
> >> > are very suitable for this particular purpose, because you need two-way
> >> > communication between the power manager and the processes it's going to
> >> > notify (because it has to wait for the processes to finish their preparations
> >> > and to tell it that they are ready). 
> 
> Wouldn't there need to be dependecy tracking for the userspace processes? A 
> process couldn't signal "done" until it know there's no more work to do, which 
> requires all other processes to finish up first.
> 

Not all processes will need pm notification.

Just in case, could this "power manager" be provided as userspace
driver for kernel (for example compiled as UIO)?

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > 
> > rjw@sisk.pl said:
> > >> > I don't see a problem with this in principle, although I don't think signals
> > >> > are very suitable for this particular purpose, because you need two-way
> > >> > communication between the power manager and the processes it's going to
> > >> > notify (because it has to wait for the processes to finish their preparations
> > >> > and to tell it that they are ready). 
> > 
> > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > process couldn't signal "done" until it know there's no more work to do, which 
> > requires all other processes to finish up first.
> > 
> 
> Not all processes will need pm notification.
> 
> Just in case, could this "power manager" be provided as userspace
> driver for kernel (for example compiled as UIO)?

I don't really understand why you want to do that in the kernel.  Is there
any particular reason why this cannot be done in the user space?

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 5 stycznia 2010 22:23 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> > Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > > 
> > > rjw@sisk.pl said:
> > > >> > I don't see a problem with this in principle, although I don't think signals
> > > >> > are very suitable for this particular purpose, because you need two-way
> > > >> > communication between the power manager and the processes it's going to
> > > >> > notify (because it has to wait for the processes to finish their preparations
> > > >> > and to tell it that they are ready). 
> > > 
> > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > process couldn't signal "done" until it know there's no more work to do, which 
> > > requires all other processes to finish up first.
> > > 
> > 
> > Not all processes will need pm notification.
> > 
> > Just in case, could this "power manager" be provided as userspace
> > driver for kernel (for example compiled as UIO)?
> 
> I don't really understand why you want to do that in the kernel.  Is there
> any particular reason why this cannot be done in the user space?
> 

Problem is with notification from pm-utils. Dbus for session is only 
user session waid and it is almost imposible to send something 
from systembus or it needs lots of magic.

Even if i'll use pm-utils, must provide way to notify my app.
Looks like no standard way here, that's bad, every app has it's own?

I think this way - if kernel is processes manager and if it sends
"some unknown" signal to every process before kernel suspend so why
not send sepcific and known signal instread.

But now we have DeviceKit-power/upower whatever but it doesn't provide
this feature or something simmilar to relay on.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 22:23 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> > > Dnia 5 stycznia 2010 10:07 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> > > > 
> > > > rjw@sisk.pl said:
> > > > >> > I don't see a problem with this in principle, although I don't think signals
> > > > >> > are very suitable for this particular purpose, because you need two-way
> > > > >> > communication between the power manager and the processes it's going to
> > > > >> > notify (because it has to wait for the processes to finish their preparations
> > > > >> > and to tell it that they are ready). 
> > > > 
> > > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > > process couldn't signal "done" until it know there's no more work to do, which 
> > > > requires all other processes to finish up first.
> > > > 
> > > 
> > > Not all processes will need pm notification.
> > > 
> > > Just in case, could this "power manager" be provided as userspace
> > > driver for kernel (for example compiled as UIO)?
> > 
> > I don't really understand why you want to do that in the kernel.  Is there
> > any particular reason why this cannot be done in the user space?
> > 
> 
> Problem is with notification from pm-utils. Dbus for session is only 
> user session waid and it is almost imposible to send something 
> from systembus or it needs lots of magic.

Don't use dbus, then.

> Even if i'll use pm-utils, must provide way to notify my app.
> Looks like no standard way here, that's bad, every app has it's own?

Isn't there a possibility to introduce a standard way of doing that without
involving the kernel directly?

> I think this way - if kernel is processes manager and if it sends
> "some unknown" signal to every process before kernel suspend so why
> not send sepcific and known signal instread.

We _can_ do that, but what would a process be supposed to do after receiving
such a signal?

> But now we have DeviceKit-power/upower whatever but it doesn't provide
> this feature or something simmilar to relay on.

You're still not saying what you really need.  So, what's the application you
have in mind that needs a notification from the _kernel_ so badly?

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 6 stycznia 2010 0:03 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> You're still not saying what you really need.  So, what's the application you
> have in mind that needs a notification from the _kernel_ so badly?
> 

Ummm sorry, it's IM App, to be realible for such app it's needed to close conn
before suspend, because after resume tcp connections will wait (especialy on linux)
quiet a lot of time to broke and reconnect.

Typicaly need info "about to resume","about to suspned" or something like that.

If it is not a problem so how to send message from pm-utils sleep.d with dbus-send 
to app launched by user?

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Anders Eriksson]

uzi18@o2.pl said:
>  Ummm sorry, it's IM App, to be realible for such app it's needed to close
> conn before suspend, because after resume tcp connections will wait
> (especialy on linux) quiet a lot of time to broke and reconnect.

I don't know the details here, but shouldn't the kernel fix this internally?

If sufficient time have elapsed so the kernel _should_ have sent keep alives 
etc on an othervise idle connection, they shold be sent immediately on resume. 
If the other end has disappeared by then, the resulting port unreachable 
should trigger a local closure of the tcp state which the app will notice 
(EBADF, or similar). Or?

Seems to me the kernel should sit on enough info to handle this nicely. 

Re: [suspend/resume] Re: userspace notific ation from module

[Bartłomiej Zimoń]

Dnia 6 stycznia 2010 15:35 	Anders Eriksson <aeriksson@fastmail.fm> napisał(a):
> 
> uzi18@o2.pl said:
> >  Ummm sorry, it's IM App, to be realible for such app it's needed to close
> > conn before suspend, because after resume tcp connections will wait
> > (especialy on linux) quiet a lot of time to broke and reconnect.
> 
> I don't know the details here, but shouldn't the kernel fix this internally?
> 
> If sufficient time have elapsed so the kernel _should_ have sent keep alives 
> etc on an othervise idle connection, they shold be sent immediately on resume. 
> If the other end has disappeared by then, the resulting port unreachable 
> should trigger a local closure of the tcp state which the app will notice 
> (EBADF, or similar). Or?
> 
> Seems to me the kernel should sit on enough info to handle this nicely. 
> 

Good bohevior is client to close session before suspend to not loose any message.

Best Regards
Bartlomiej Zimon

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notific ation from module

[Roland Dreier]

thanks, applied.

Re: [suspend/resume] Re: userspace notific ation from module

[Roland Dreier]

 > thanks, applied.

MUA hickup, sorry -- replied to wrong mail.

Re: [suspend/resume] Re: userspace notification from module

[Pavel Machek]

On Wed 2010-01-06 15:35:34, Anders Eriksson wrote:
> 
> uzi18@o2.pl said:
> >  Ummm sorry, it's IM App, to be realible for such app it's needed to close
> > conn before suspend, because after resume tcp connections will wait
> > (especialy on linux) quiet a lot of time to broke and reconnect.
> 
> I don't know the details here, but shouldn't the kernel fix this internally?
> 
> If sufficient time have elapsed so the kernel _should_ have sent keep alives 
> etc on an othervise idle connection, they shold be sent immediately on resume. 
> If the other end has disappeared by then, the resulting port unreachable 
> should trigger a local closure of the tcp state which the app will notice 
> (EBADF, or similar). Or?

Patches welcome.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [suspend/resume] Re: userspace notification from module

[Stefan Seyfried]

On Tue, 05 Jan 2010 10:07:06 +0100
Anders Eriksson <aeriksson@fastmail.fm> wrote:

> 
> rjw@sisk.pl said:
> >> > I don't see a problem with this in principle, although I don't think signals
> >> > are very suitable for this particular purpose, because you need two-way
> >> > communication between the power manager and the processes it's going to
> >> > notify (because it has to wait for the processes to finish their preparations
> >> > and to tell it that they are ready). 
> 
> Wouldn't there need to be dependecy tracking for the userspace processes? A 
> process couldn't signal "done" until it know there's no more work to do, which 
> requires all other processes to finish up first.

No. 99% of the processes don't care about suspend. They don't need
notifications or anything.
The few that do care, register themselves with the power manager. They
get notified before suspend and the power manager might wait until they
tell him that they are ready.
A special case are processes that only want to inhibit suspend - the CD
burning application case - they just tell the power manager "I am
important and you must not suspend now". They do this even if there is
no suspend notification, and once they are done with the critical part
of their work, they remove their "inhibit flag".

This all works pretty well already, and is really not very complicated.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 5 stycznia 2010 22:26 	Stefan Seyfried <stefan.seyfried@googlemail.com> napisał(a):
> On Tue, 05 Jan 2010 10:07:06 +0100
> Anders Eriksson <aeriksson@fastmail.fm> wrote:
> 
> > 
> > rjw@sisk.pl said:
> > >> > I don't see a problem with this in principle, although I don't think signals
> > >> > are very suitable for this particular purpose, because you need two-way
> > >> > communication between the power manager and the processes it's going to
> > >> > notify (because it has to wait for the processes to finish their preparations
> > >> > and to tell it that they are ready). 
> > 
> > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > process couldn't signal "done" until it know there's no more work to do, which 
> > requires all other processes to finish up first.
> 
> No. 99% of the processes don't care about suspend. They don't need
> notifications or anything.
> The few that do care, register themselves with the power manager. They
> get notified before suspend and the power manager might wait until they
> tell him that they are ready.
> A special case are processes that only want to inhibit suspend - the CD
> burning application case - they just tell the power manager "I am
> important and you must not suspend now". They do this even if there is
> no suspend notification, and once they are done with the critical part
> of their work, they remove their "inhibit flag".
> 
> This all works pretty well already, and is really not very complicated.

So pm could be very simple, and i think we don't need more.
I want ask You how usualy such user (not root) process notification is done,
You are talking about pm-utils right?

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Tuesday 05 January 2010, Bartłomiej Zimoń wrote:
> Dnia 5 stycznia 2010 22:26 	Stefan Seyfried <stefan.seyfried@googlemail.com> napisał(a):
> > On Tue, 05 Jan 2010 10:07:06 +0100
> > Anders Eriksson <aeriksson@fastmail.fm> wrote:
> > 
> > > 
> > > rjw@sisk.pl said:
> > > >> > I don't see a problem with this in principle, although I don't think signals
> > > >> > are very suitable for this particular purpose, because you need two-way
> > > >> > communication between the power manager and the processes it's going to
> > > >> > notify (because it has to wait for the processes to finish their preparations
> > > >> > and to tell it that they are ready). 
> > > 
> > > Wouldn't there need to be dependecy tracking for the userspace processes? A 
> > > process couldn't signal "done" until it know there's no more work to do, which 
> > > requires all other processes to finish up first.
> > 
> > No. 99% of the processes don't care about suspend. They don't need
> > notifications or anything.
> > The few that do care, register themselves with the power manager. They
> > get notified before suspend and the power manager might wait until they
> > tell him that they are ready.
> > A special case are processes that only want to inhibit suspend - the CD
> > burning application case - they just tell the power manager "I am
> > important and you must not suspend now". They do this even if there is
> > no suspend notification, and once they are done with the critical part
> > of their work, they remove their "inhibit flag".
> > 
> > This all works pretty well already, and is really not very complicated.
> 
> So pm could be very simple, and i think we don't need more.
> I want ask You how usualy such user (not root) process notification is done,
> You are talking about pm-utils right?

Well, I think you have some specific issue with pm-utils, but you're not
telling us what it is.  So, why exactly is pm-utils not suitable for your
needs?

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 6 stycznia 2010 0:05 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> Well, I think you have some specific issue with pm-utils, but you're not
> telling us what it is.  So, why exactly is pm-utils not suitable for your
> needs?
> 

Rafael to be honest it's more dbus specific. I'm talking about 
dbus as it is standard for system<->apps communication.

But please understand if we'll create kernel device with simple pm notification
It could be hooked by udev and next ... by DeviceKit-power/upower and after that
we have real standard. But to have this we must export "power" device - something 
like my proof-of-concept module. This could be realy good start.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Stefan Seyfried]

Hi,

On Tue, 05 Jan 2010 23:22:19 +0100
Bartłomiej Zimoń <uzi18@o2.pl> wrote:

> So pm could be very simple, and i think we don't need more.
> I want ask You how usualy such user (not root) process notification is done,
> You are talking about pm-utils right?

No, not at all.
Once you are at a level where pm-utils does its job, the Network is
hopefully already disconnected and the external storage umounted etc..

So you do not send the message from pm-utils, but from the power
manager app. Once you are done with preparing the suspend in the users
session (telling your email and IM app to go offline etc), then you
call HAL's suspend method (or whoever is in charge of that now,
DevKit?).

Implementation detail: probably the power manager app just tells the
network manager app to shut down the network when going to suspend, and
the network manager app tells the email and im app to go offline, this
would at least make much more sense to me ;)

I see why you are tempted to put this into the kernel. However, this is
IMHO not the best way, because you might need to interact with the user
like "I could not umount the USB stick, continue suspend?" (with a
timeout of 10 seconds and default "ok, don't care about the FS and
continue") and that is pretty complicated to do from outside the
desktop session.

(Note that I am in no way totally up-to-date how this is implemented
 nowadays and it would be definitely a good idea to talk to the pm-utils
 and the desktop developers, e.g. the gnome-power-manager guys about
 those issues).

Have fun,

	Stefan

-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Monday 04 January 2010, Daniel Borkmann wrote:
> Rafael J. Wysocki wrote:
> > On Monday 04 January 2010, Bartłomiej Zimoń wrote:
> >> And what do You think about sending extra signals to processes?
> > 
> > I don't see a problem with this in principle, although I don't think signals
> > are very suitable for this particular purpose, because you need two-way
> > communication between the power manager and the processes it's going to
> > notify (because it has to wait for the processes to finish their preparations
> > and to tell it that they are ready).
> 
> Again, just to abandon some thoughts... do you really need that "two-way
> communication"? I mean if the kernel delivers that specific signal to
> the process/task_struct [do_signal():handle_signal()] it has to save the
> original execution context that will later on be restored after the
> non-default signal handling function returns. This is our ACK /
> notification for the successful return of the programs "suspend
> handler". The kernel module (if such exists) could be notified about
> that for instance by a simple notifier hook within kernelspace. I mean
> if I see this right, the "two-way" is just for the ACK isn't it?

_If_ the kernel sends the signals, which is not I think should be done.

Please keep that in the user space.  Really.

I don't see _any_ good reason for putting such things into the kernel.

Rafael

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 3 stycznia 2010 0:29 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > - 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.
> 

So if it is bad idea, we could create more advenced implementation.
i.e. IPC or callbacks for this kind of events.

There is vision in my mind to have alternative to pm-utils, 
but even more powerfull and easy to implement in program.
I could try to implement something like that.

Rafael i'm open for Your suggestions.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Sunday 03 January 2010, Bartłomiej Zimoń wrote:
> Dnia 3 stycznia 2010 0:29 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > > - 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.
> > 
> 
> So if it is bad idea, we could create more advenced implementation.
> i.e. IPC or callbacks for this kind of events.
> 
> There is vision in my mind to have alternative to pm-utils, 
> but even more powerfull and easy to implement in program.
> I could try to implement something like that.

I guess there's no other way to show people what you're up to, so please go
ahead and let me know if you need help.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > > 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.
> > 
> > Because now kernel know better what is going on.
> 
> That's because it's just been told by the user space about that.
> 
> Basically, you want something like this to happen:
> 
> process A ->(suspend) kernel
> kernel ->(suspending) process B
> 

Yes.

> where the kernel won't wait for process B to do whatever it has to do before
> suspending.  In my opinion it'd be better to do something like this
> 
> process A ->(suspending) process B
> process B ->(ack) process A
> process A ->(suspend) kernel
> 
> ... 

Please forget for a moment about pm-utils.

I was thinking about sf like this:
pm-notify is registered in pm_notifier_chain or called before pm_notifiers_chain
pm-notify -> (suspending) all registerd processes
some processes ->(ack) pm-notify
to consider - after timeout ( 1s. could be ok) pm-notify will send NOTIFY_OK, kernel will cont. suspending

It could be even UIO module but there are no pm events reachable there?

I cant understand why kernel cant be simple power manager.

Consider this: add one more signal (SIGPREFREEZ, SIGPOSTFREEZ) and send this before/after suspend to processes.
It could be simplest way and we have notified processes.

If pm-notify idea is not clean, we must extend pm-utils or write something new
(with backends dbus, ipc, scripts, ...)
But You see? We still have no information from kernel about events 
(especialy resume) or maybe i dont see this ;/

Thanks for your understanding Rafael :)

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Bartłomiej Zimoń]

Dnia 6 stycznia 2010 0:05 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> Well, I think you have some specific issue with pm-utils, but you're not
> telling us what it is.  So, why exactly is pm-utils not suitable for your
> needs?
> 

Rafael to be honest it's more dbus specific. I'm talking about 
dbus as it is standard for system<->apps communication.

But please understand if we'll create kernel device with simple pm notification
It could be hooked by udev and next ... by DeviceKit-power/upower and after that
we have real standard. But to have this we must export "power" device - something 
like my proof-of-concept module. This could be realy good start.

Best regards.
Bartłomiej Zimoń
PLD Linux, Kadu Team, FreeRunner user
http://kadu-im.blogspot.com/


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [suspend/resume] Re: userspace notification from module

[Rafael J. Wysocki]

On Wednesday 06 January 2010, Bartłomiej Zimoń wrote:
> Dnia 6 stycznia 2010 0:05 	"Rafael J. Wysocki" <rjw@sisk.pl> napisał(a):
> > Well, I think you have some specific issue with pm-utils, but you're not
> > telling us what it is.  So, why exactly is pm-utils not suitable for your
> > needs?
> > 
> 
> Rafael to be honest it's more dbus specific. I'm talking about 
> dbus as it is standard for system<->apps communication.

That was my impression. :-)

Well, I don't like dbus too, but ...

> But please understand if we'll create kernel device with simple pm notification
> It could be hooked by udev and next ... by DeviceKit-power/upower and after that
> we have real standard. But to have this we must export "power" device - something 
> like my proof-of-concept module. This could be realy good start.

... that doesn't make me think it should be sneakily replaced with "magic"
kernel modules or similar stuff.

As I already said many times in this thread before, please look for a solution
in the user space.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm