Power event notification patch

Power event notification patch

[V, Sankara Narayanan]

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

Hi Folks,

 

Here is a simple patch for power event notification to user-space
applications. Basically, what it does is notify the user-space
applications that the system is going to a low power state
(Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This is
useful for the user-space applications to do some significant action
when the system goes to the low power state (like saving an unsaved
file). The user-space objects can form a netlink socket and listen to
these events. It is done through a kobject-netlink socket. For this I
have used the kobject_uevent system call, posting the notification to
user space with standby, hibernate and resume in the action parameter of
the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
enums). Appreciate your comments on the patch.

 

Thanks,

Sankara Narayanan V.

 


[-- Attachment #1.2: Type: text/html, Size: 3573 bytes --]

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

Re: Power event notification patch

[Oliver Neukum]

Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> Here is a simple patch for power event notification to user-space
> applications. Basically, what it does is notify the user-space
> applications that the system is going to a low power state
> (Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This is
> useful for the user-space applications to do some significant action
> when the system goes to the low power state (like saving an unsaved
> file). The user-space objects can form a netlink socket and listen to
> these events. It is done through a kobject-netlink socket. For this I
> have used the kobject_uevent system call, posting the notification to
> user space with standby, hibernate and resume in the action parameter of
> the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
> enums). Appreciate your comments on the patch.

Why does this need to be done in kernel space?
How do you want to make sure user space has enough time to act on a
notification?

	Regards
		Oliver

RE: Power event notification patch

[V, Sankara Narayanan]

1. Isn't it the kernel which is finally initiating a low power sleep
state? So, I added it in kernel/power/main.c where the kernel does all
the suspend related activities.

2. To answer your second question, we really can't guarantee. But even
if you take Windows Vista (sorry linux enthusiasts for referring windows
here) or any other non-UNIX operating systems (which has this power
event notification), they really do not guarantee it. But, it is an
era-of-tera and the user space applications can do some minimal work
like saving the app's last state in a .tmp file or so (like firefox if
closed in an unclean way) to restore their state.

I have tested it over some applications of my own and they seem to
execute a significant piece of code-like writing to a file when they go
to low power state.

Really appreciate your comment. Thanks.
 
Thanks,
Sankara Narayanan V.

-----Original Message-----
From: Oliver Neukum [mailto:oliver@neukum.org] 
Sent: Thursday, July 05, 2007 5:38 PM
To: linux-pm@lists.linux-foundation.org
Cc: V, Sankara Narayanan
Subject: Re: [linux-pm] Power event notification patch

Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> Here is a simple patch for power event notification to user-space
> applications. Basically, what it does is notify the user-space
> applications that the system is going to a low power state
> (Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This
is
> useful for the user-space applications to do some significant action
> when the system goes to the low power state (like saving an unsaved
> file). The user-space objects can form a netlink socket and listen to
> these events. It is done through a kobject-netlink socket. For this I
> have used the kobject_uevent system call, posting the notification to
> user space with standby, hibernate and resume in the action parameter
of
> the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
> enums). Appreciate your comments on the patch.

Why does this need to be done in kernel space?
How do you want to make sure user space has enough time to act on a
notification?

	Regards
		Oliver

Re: Power event notification patch

[Oliver Neukum]

Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> 1. Isn't it the kernel which is finally initiating a low power sleep
> state? So, I added it in kernel/power/main.c where the kernel does all
> the suspend related activities.

Not really. The kernel takes the system to sleep if somebody with
the proper credentials tells it to do so. The kernel doesn't take the
initiative.

So the most obvious place to do the notification is with the entity
that initiates the sleep.

> 2. To answer your second question, we really can't guarantee. But even
> if you take Windows Vista (sorry linux enthusiasts for referring windows
> here) or any other non-UNIX operating systems (which has this power
> event notification), they really do not guarantee it. But, it is an
> era-of-tera and the user space applications can do some minimal work
> like saving the app's last state in a .tmp file or so (like firefox if
> closed in an unclean way) to restore their state.

Well, we want to better than that other OS.

If you do this in user space, eg. the pm utilities, you can easily implement
policies like waiting x seconds for the rest of the system to respond.

	Regards
		Oliver

RE: Power event notification patch

[V, Sankara Narayanan]

Well, say I have two applications, say app1 and app2. App 1 initiates a
suspend-to-RAM. How will app2 come to know the system is going to sleep.
Only way is app1 needs to inform/broadcast that the application has
initiates the sleep or the system is going to sleep. In that case, every
application which initiates a sleep has to implement this. Quoting your
example, the user who has proper credentials (using whatever application
he uses to initiate a sleep) should tell each application when going to
sleep. Even when we use pm-utilities, please understand that the
kernel/power/main.c's enter_state executes the first call/instruction to
prepare the system for the low power state.

So, it is apt to keep it in kernel space.

Thanks,
Sankar.

-----Original Message-----
From: Oliver Neukum [mailto:oliver@neukum.org] 
Sent: Thursday, July 05, 2007 6:05 PM
To: V, Sankara Narayanan
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: [linux-pm] Power event notification patch

Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> 1. Isn't it the kernel which is finally initiating a low power sleep
> state? So, I added it in kernel/power/main.c where the kernel does all
> the suspend related activities.

Not really. The kernel takes the system to sleep if somebody with
the proper credentials tells it to do so. The kernel doesn't take the
initiative.

So the most obvious place to do the notification is with the entity
that initiates the sleep.

> 2. To answer your second question, we really can't guarantee. But even
> if you take Windows Vista (sorry linux enthusiasts for referring
windows
> here) or any other non-UNIX operating systems (which has this power
> event notification), they really do not guarantee it. But, it is an
> era-of-tera and the user space applications can do some minimal work
> like saving the app's last state in a .tmp file or so (like firefox if
> closed in an unclean way) to restore their state.

Well, we want to better than that other OS.

If you do this in user space, eg. the pm utilities, you can easily
implement
policies like waiting x seconds for the rest of the system to respond.

	Regards
		Oliver

Re: Power event notification patch

[Oliver Neukum]

Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> Well, say I have two applications, say app1 and app2. App 1 initiates a
> suspend-to-RAM. How will app2 come to know the system is going to sleep.
> Only way is app1 needs to inform/broadcast that the application has
> initiates the sleep or the system is going to sleep. In that case, every
> application which initiates a sleep has to implement this. Quoting your

Yes, that is a situation that screams for implementation in a library.
Preferably through using multicast channels, like DBUS.

	Regards
		Oliver

RE: Power event notification patch

[Igor Stoppa]

Hi,
On Thu, 2007-07-05 at 18:14 +0530, ext V, Sankara Narayanan wrote:
> Well, say I have two applications, say app1 and app2. App 1 initiates a
> suspend-to-RAM. How will app2 come to know the system is going to sleep.

Apparently you are not concernedd about giving a NACK, just let other
apps know that the transition is going to happen.

And you have admitted that it's not possible to have a deterministic
response (apps have "some" time to do "something").

If your system relies on such weak mechanism, it's well broken.

An application that wants to keep its state saved somewhere safe
(meaning that it can survive a powercycle) should store it asap, not
when something risky might happen.

> Only way is app1 needs to inform/broadcast that the application has
> initiates the sleep or the system is going to sleep. In that case, every
> application which initiates a sleep has to implement this. Quoting your
> example, the user who has proper credentials (using whatever application
> he uses to initiate a sleep) should tell each application when going to
> sleep. Even when we use pm-utilities, please understand that the
> kernel/power/main.c's enter_state executes the first call/instruction to
> prepare the system for the low power state.
> 
> So, it is apt to keep it in kernel space.

Not really, it belongs to userspace, and only to those apps that need
it.

Implement a library to make it in a standardized, but keep it away from
kernelspace. Actually I think you can get already something similar from
Hildon.

Have you checked that?

cheers,
igor

> Thanks,
> Sankar.
> 
> -----Original Message-----
> From: Oliver Neukum [mailto:oliver@neukum.org] 
> Sent: Thursday, July 05, 2007 6:05 PM
> To: V, Sankara Narayanan
> Cc: linux-pm@lists.linux-foundation.org
> Subject: Re: [linux-pm] Power event notification patch
> 
> Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> > 1. Isn't it the kernel which is finally initiating a low power sleep
> > state? So, I added it in kernel/power/main.c where the kernel does all
> > the suspend related activities.
> 
> Not really. The kernel takes the system to sleep if somebody with
> the proper credentials tells it to do so. The kernel doesn't take the
> initiative.
> 
> So the most obvious place to do the notification is with the entity
> that initiates the sleep.
> 
> > 2. To answer your second question, we really can't guarantee. But even
> > if you take Windows Vista (sorry linux enthusiasts for referring
> windows
> > here) or any other non-UNIX operating systems (which has this power
> > event notification), they really do not guarantee it. But, it is an
> > era-of-tera and the user space applications can do some minimal work
> > like saving the app's last state in a .tmp file or so (like firefox if
> > closed in an unclean way) to restore their state.
> 
> Well, we want to better than that other OS.
> 
> If you do this in user space, eg. the pm utilities, you can easily
> implement
> policies like waiting x seconds for the rest of the system to respond.
> 
> 	Regards
> 		Oliver
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

RE: Power event notification patch

[V, Sankara Narayanan]

Guys,

You really can't depend on this if your application want to execute some
10000 lines of code. What I told is the app will have enough time to do
some minimal work (say wanna do some cleanup which is of the order of
100 instructions or so). The go-to-suspend time is of the order of 2.x
seconds. So, we can really do it.

Igor,
I really do not understand what you mean by NACK (is it No ACK? If yes,
please explain)

Johannes,
In that case, you need to implement it in every power manager and in
turn HAL and DBUS get these from the kernel, one more redirection which
will further reduce the time for the app to do the 'minimal' work.

Thanks,
Sankar.

-----Original Message-----
From: Igor Stoppa [mailto:igor.stoppa@nokia.com] 
Sent: Thursday, July 05, 2007 6:25 PM
To: V, Sankara Narayanan
Cc: Oliver Neukum; linux-pm@lists.linux-foundation.org
Subject: RE: [linux-pm] Power event notification patch

Hi,
On Thu, 2007-07-05 at 18:14 +0530, ext V, Sankara Narayanan wrote:
> Well, say I have two applications, say app1 and app2. App 1 initiates
a
> suspend-to-RAM. How will app2 come to know the system is going to
sleep.

Apparently you are not concernedd about giving a NACK, just let other
apps know that the transition is going to happen.

And you have admitted that it's not possible to have a deterministic
response (apps have "some" time to do "something").

If your system relies on such weak mechanism, it's well broken.

An application that wants to keep its state saved somewhere safe
(meaning that it can survive a powercycle) should store it asap, not
when something risky might happen.

> Only way is app1 needs to inform/broadcast that the application has
> initiates the sleep or the system is going to sleep. In that case,
every
> application which initiates a sleep has to implement this. Quoting
your
> example, the user who has proper credentials (using whatever
application
> he uses to initiate a sleep) should tell each application when going
to
> sleep. Even when we use pm-utilities, please understand that the
> kernel/power/main.c's enter_state executes the first call/instruction
to
> prepare the system for the low power state.
> 
> So, it is apt to keep it in kernel space.

Not really, it belongs to userspace, and only to those apps that need
it.

Implement a library to make it in a standardized, but keep it away from
kernelspace. Actually I think you can get already something similar from
Hildon.

Have you checked that?

cheers,
igor

> Thanks,
> Sankar.
> 
> -----Original Message-----
> From: Oliver Neukum [mailto:oliver@neukum.org] 
> Sent: Thursday, July 05, 2007 6:05 PM
> To: V, Sankara Narayanan
> Cc: linux-pm@lists.linux-foundation.org
> Subject: Re: [linux-pm] Power event notification patch
> 
> Am Donnerstag, 5. Juli 2007 schrieb V, Sankara Narayanan:
> > 1. Isn't it the kernel which is finally initiating a low power sleep
> > state? So, I added it in kernel/power/main.c where the kernel does
all
> > the suspend related activities.
> 
> Not really. The kernel takes the system to sleep if somebody with
> the proper credentials tells it to do so. The kernel doesn't take the
> initiative.
> 
> So the most obvious place to do the notification is with the entity
> that initiates the sleep.
> 
> > 2. To answer your second question, we really can't guarantee. But
even
> > if you take Windows Vista (sorry linux enthusiasts for referring
> windows
> > here) or any other non-UNIX operating systems (which has this power
> > event notification), they really do not guarantee it. But, it is an
> > era-of-tera and the user space applications can do some minimal work
> > like saving the app's last state in a .tmp file or so (like firefox
if
> > closed in an unclean way) to restore their state.
> 
> Well, we want to better than that other OS.
> 
> If you do this in user space, eg. the pm utilities, you can easily
> implement
> policies like waiting x seconds for the rest of the system to respond.
> 
> 	Regards
> 		Oliver
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

RE: Power event notification patch

[Johannes Berg]

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

On Thu, 2007-07-05 at 18:39 +0530, V, Sankara Narayanan wrote:

> Johannes,
> In that case, you need to implement it in every power manager and in
> turn HAL and DBUS get these from the kernel, one more redirection which
> will further reduce the time for the app to do the 'minimal' work.

No, as far as I know it'll actually tell applications *before* telling
the kernel.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

RE: Power event notification patch

[V, Sankara Narayanan]

We have to confirm that. And even if that does, running just linux
kernel as OS without these applications/libraries does not guarantee the
power notification. It means that I have to run these apps/libraries
wherever I want power event notification (example embedded devices).

Thanks,
Sankar.

-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Thursday, July 05, 2007 6:43 PM
To: V, Sankara Narayanan
Cc: Igor Stoppa; Oliver Neukum; linux-pm@lists.linux-foundation.org
Subject: RE: [linux-pm] Power event notification patch

On Thu, 2007-07-05 at 18:39 +0530, V, Sankara Narayanan wrote:

> Johannes,
> In that case, you need to implement it in every power manager and in
> turn HAL and DBUS get these from the kernel, one more redirection
which
> will further reduce the time for the app to do the 'minimal' work.

No, as far as I know it'll actually tell applications *before* telling
the kernel.

johannes

RE: Power event notification patch

[Johannes Berg]

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

On Thu, 2007-07-05 at 18:47 +0530, V, Sankara Narayanan wrote:
> We have to confirm that. And even if that does, running just linux
> kernel as OS without these applications/libraries does not guarantee the
> power notification. 

True.

> It means that I have to run these apps/libraries
> wherever I want power event notification (example embedded devices).

Well, if you have a truly embedded device then likely you don't care
about this at all since the applications will work together much closer
than on a desktop system. Also, you likely have much stricter
requirements in that each application *must* be able to do exactly steps
1/2/3 before the system is suspended. Also, suspend will likely be
*much* faster too.

If it's pseudo-embedded like Nokia's N770/800 then you can very well run
things like hal to handle it.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

RE: Power event notification patch

[V, Sankara Narayanan]

Yeah! If it is a pseudo-embedded device, it can take care of because the
application ecosystem is already established there. It won't be a
generic thing for all embedded devices. Of course, every application
receives the event and it can act on the way it wants (I did not
understand step 1/2/3...). 

Thanks,
Sankar.

-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Thursday, July 05, 2007 6:58 PM
To: V, Sankara Narayanan
Cc: Igor Stoppa; Oliver Neukum; linux-pm@lists.linux-foundation.org
Subject: RE: [linux-pm] Power event notification patch

On Thu, 2007-07-05 at 18:47 +0530, V, Sankara Narayanan wrote:
> We have to confirm that. And even if that does, running just linux
> kernel as OS without these applications/libraries does not guarantee
the
> power notification. 

True.

> It means that I have to run these apps/libraries
> wherever I want power event notification (example embedded devices).

Well, if you have a truly embedded device then likely you don't care
about this at all since the applications will work together much closer
than on a desktop system. Also, you likely have much stricter
requirements in that each application *must* be able to do exactly steps
1/2/3 before the system is suspended. Also, suspend will likely be
*much* faster too.

If it's pseudo-embedded like Nokia's N770/800 then you can very well run
things like hal to handle it.

johannes

RE: Power event notification patch

[Johannes Berg]

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

On Thu, 2007-07-05 at 19:03 +0530, V, Sankara Narayanan wrote:
> Yeah! If it is a pseudo-embedded device, it can take care of because the
> application ecosystem is already established there. It won't be a
> generic thing for all embedded devices. Of course, every application
> receives the event and it can act on the way it wants (I did not
> understand step 1/2/3...). 

By "steps 1/2/3" I was just trying to say that each application probably
has multiple steps that should be guaranteed to run before it can
rightfully say it has saved all state for the event that the system
never wakes up or whatever else it needs. But if you have more
applications the chances of it running successfully diminish quickly.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

Re: Power event notification patch

[Scott Preece]

On 7/5/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2007-07-05 at 18:47 +0530, V, Sankara Narayanan wrote:
> > We have to confirm that. And even if that does, running just linux
> > kernel as OS without these applications/libraries does not guarantee the
> > power notification.
>
> True.
>
> > It means that I have to run these apps/libraries
> > wherever I want power event notification (example embedded devices).
>
> Well, if you have a truly embedded device then likely you don't care
> about this at all since the applications will work together much closer
> than on a desktop system. Also, you likely have much stricter
> requirements in that each application *must* be able to do exactly steps
> 1/2/3 before the system is suspended. Also, suspend will likely be
> *much* faster too.
>
> If it's pseudo-embedded like Nokia's N770/800 then you can very well run
> things like hal to handle it.
>
> johannes
--

On most embedded devices, power-management does not involve user
action. In many devices the actions are all initiated in the kernel,
in others they are *enabled* in userspace and carried out n the kernel
(some people argue that responsiveness requires that it be there,
others that it's policy and belongs in user space). In any case, the
kernel usually needs to do some steps that may or may not allow the
system to go to sleep (for instance, asking devices to suspend, which
they are allowed to reject).

I tend to think that the kernel is the only place where a notice can
be sent out only if the system is going to sleep.

However, there's a paradox there. The kernel doesn't know it can go to
sleep until the devices have suspended, which means that apps could be
notified but would have to option to save state anyway, since they
would have no devices to write it to.

In any case, I haven't heard a really convincing argument for
notifications to apps. If you have a real NEED for apps to be able to
save state, then you need a mechanism that allows them to reject the
event until they're safe...

-- 
scott preece

RE: Power event notification patch

[Johannes Berg]

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

On Thu, 2007-07-05 at 15:13 +0200, Johannes Berg wrote:

> No, as far as I know it'll actually tell applications *before* telling
> the kernel.

Huh, looks like I was wrong, it only specifically tells gnome-keyring,
gnome-network-manager and gnome-screensaver. But it could very well
broadcast something too.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

RE: Power event notification patch

[Igor Stoppa]

On Thu, 2007-07-05 at 18:39 +0530, ext V, Sankara Narayanan wrote:
> Guys,
> 
> You really can't depend on this if your application want to execute some
> 10000 lines of code. What I told is the app will have enough time to do
> some minimal work (say wanna do some cleanup which is of the order of
> 100 instructions or so). The go-to-suspend time is of the order of 2.x
> seconds. So, we can really do it.
> 
> Igor,
> I really do not understand what you mean by NACK (is it No ACK? If yes,
> please explain)

You are not expecting another app (say app2) to veto (No ACK) what your
master app (app1) has decided.

You only want app 2 to take care of itself so that its internal state
(the part you care about) will be available for restoring, should something
go bad. That, btw, is the same situation as with the OOM killer.


Your assumption to do something when the system starts to go in suspended
mode is dangerous and, as i said, not really safe.

Instead, if you save your application state when it changes (i.e. the user
opens a new tab in the browser) you will be able to restore the application
state in _any_ case, not just for a failed suspend.

It's cleaner, deterministic and doesn't introduce artificial dependencies
on kernelspace.
Keep also in mind that your numbers are probably bogus on different
architectures and your solution might not work (yes, i've seen your email
address but that doesn't justify the creation of arch-specific coded when
it's not necessary ;-)

-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

RE: Power event notification patch

[V, Sankara Narayanan]

I really can't stop the kernel from going to suspend using my master app
(well, my app is not really a master app). It is just to inform the apps
in the user space "Hey, I'm going to suspend, in the time available
before I go to sleep, do whatever you can do!" whenever kernel goes to
sleep. And I'm really can't stop the kernel from going to sleep (from a
theoretical point I can do that as well, but at least I have not
implemented that).

Thanks,
Sankar.

-----Original Message-----
From: Igor Stoppa [mailto:igor.stoppa@nokia.com] 
Sent: Thursday, July 05, 2007 6:51 PM
To: V, Sankara Narayanan
Cc: johannes@sipsolutions.net; Oliver Neukum;
linux-pm@lists.linux-foundation.org
Subject: RE: [linux-pm] Power event notification patch

On Thu, 2007-07-05 at 18:39 +0530, ext V, Sankara Narayanan wrote:
> Guys,
> 
> You really can't depend on this if your application want to execute
some
> 10000 lines of code. What I told is the app will have enough time to
do
> some minimal work (say wanna do some cleanup which is of the order of
> 100 instructions or so). The go-to-suspend time is of the order of 2.x
> seconds. So, we can really do it.
> 
> Igor,
> I really do not understand what you mean by NACK (is it No ACK? If
yes,
> please explain)

You are not expecting another app (say app2) to veto (No ACK) what your
master app (app1) has decided.

You only want app 2 to take care of itself so that its internal state
(the part you care about) will be available for restoring, should
something
go bad. That, btw, is the same situation as with the OOM killer.


Your assumption to do something when the system starts to go in
suspended
mode is dangerous and, as i said, not really safe.

Instead, if you save your application state when it changes (i.e. the
user
opens a new tab in the browser) you will be able to restore the
application
state in _any_ case, not just for a failed suspend.

It's cleaner, deterministic and doesn't introduce artificial
dependencies
on kernelspace.
Keep also in mind that your numbers are probably bogus on different
architectures and your solution might not work (yes, i've seen your
email
address but that doesn't justify the creation of arch-specific coded
when
it's not necessary ;-)

-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

RE: Power event notification patch

[Igor Stoppa]

Hi,
On Thu, 2007-07-05 at 19:09 +0530, ext V, Sankara Narayanan wrote:
> I really can't stop the kernel from going to suspend using my master app
> (well, my app is not really a master app). It is just to inform the apps
> in the user space "Hey, I'm going to suspend, in the time available
> before I go to sleep, do whatever you can do!" whenever kernel goes to
> sleep. And I'm really can't stop the kernel from going to sleep (from a
> theoretical point I can do that as well, but at least I have not
> implemented that).

Yes, i've understood that.

What i'm saying is that your approach:

"Hey, I'm going to suspend, in the time available before I go to sleep,
do whatever you can do!"

is faulty, imo.


What we are doing in Maemo is:

App1 changes states -> App1 saves its state using library
App2 changes states -> App2 saves its state using library
App3 changes states -> App3 saves its state using library
App4 changes states -> App4 saves its state using library
....

Suspend event -> Apps do nothing 


Very simple and deterministic. Note also that you can track is Apps are
saving their state by refcounting and therefore delaying the actual
suspend command.

I hope that it's clear now.

cheers, igor

-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

Re: Power event notification patch

[Johannes Berg]

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

On Thu, 2007-07-05 at 14:34 +0200, Oliver Neukum wrote:

> If you do this in user space, eg. the pm utilities, you can easily implement
> policies like waiting x seconds for the rest of the system to respond.

If you use gnome-power-manager (or probably the kde equivalent too) and
hal to suspend you have this already I think.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

Re: Power event notification patch

[Greg KH]

On Thu, Jul 05, 2007 at 05:31:33PM +0530, V, Sankara Narayanan wrote:
> Hi Folks,
> 
>  
> 
> Here is a simple patch for power event notification to user-space
> applications. Basically, what it does is notify the user-space
> applications that the system is going to a low power state
> (Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This is
> useful for the user-space applications to do some significant action
> when the system goes to the low power state (like saving an unsaved
> file). The user-space objects can form a netlink socket and listen to
> these events. It is done through a kobject-netlink socket. For this I
> have used the kobject_uevent system call, posting the notification to
> user space with standby, hibernate and resume in the action parameter of
> the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
> enums). Appreciate your comments on the patch.

As others have stated, this is not acceptable for a wide range of
reasons.

Not the least being that even if you did implement this, you would need
to be listening to the dbus notification of this message, and so, just
do it all in userspace anyway, no kernel involvement is needed.

Oh, and the names S3, S4, don't mean much for non-intel based
processors, so that's also not acceptable.

thanks,

greg k-h

RE: Power event notification patch

[V, Sankara Narayanan]

Dbus is a distro specific thing and you cannot be really dependent on
that if you are going for real time systems. Also, they have their own
bindings for the notification support (dbus-glib and dbus-qt). One more
drawback with dbus (apart from the above one), it will be another
redirection before our application receives the notification). Also, if
you say S3/S4 are PC oriented (or intel specific; It is mentioned in
ACPI spec.) terms, the suspend-to-ram and to disk is not necessarily PC
(or intel) oriented. 

Thanks,
Sankar.
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com] 
Sent: Saturday, July 07, 2007 12:12 AM
To: V, Sankara Narayanan
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: [linux-pm] Power event notification patch

On Thu, Jul 05, 2007 at 05:31:33PM +0530, V, Sankara Narayanan wrote:
> Hi Folks,
> 
>  
> 
> Here is a simple patch for power event notification to user-space
> applications. Basically, what it does is notify the user-space
> applications that the system is going to a low power state
> (Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This
is
> useful for the user-space applications to do some significant action
> when the system goes to the low power state (like saving an unsaved
> file). The user-space objects can form a netlink socket and listen to
> these events. It is done through a kobject-netlink socket. For this I
> have used the kobject_uevent system call, posting the notification to
> user space with standby, hibernate and resume in the action parameter
of
> the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
> enums). Appreciate your comments on the patch.

As others have stated, this is not acceptable for a wide range of
reasons.

Not the least being that even if you did implement this, you would need
to be listening to the dbus notification of this message, and so, just
do it all in userspace anyway, no kernel involvement is needed.

Oh, and the names S3, S4, don't mean much for non-intel based
processors, so that's also not acceptable.

thanks,

greg k-h

Re: Power event notification patch

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


On Mon, Jul 09, 2007 at 10:04:42AM +0530, V, Sankara Narayanan wrote:
> Dbus is a distro specific thing and you cannot be really dependent on
> that if you are going for real time systems.

And you can't depend on this message getting out either if you are using
a "real time system", so that's not an argument to add this at all,
sorry.

And yes, dbus is on _all_ distros these days, you will not have a
working system without much functionality if you do not have it (heck,
even the nokia devices use it.)

> Also, they have their own bindings for the notification support
> (dbus-glib and dbus-qt).

I don't see this being a problem, why do you?  No one forces you to use
those bindings, you can listen to "raw" dbus messages quite easy from a
simple C program if you want to.

> One more drawback with dbus (apart from the above one), it will be
> another redirection before our application receives the notification).

You already have that if you are using udev, as udev will be the one
that grabs this uevent and passes it to dbus anyway.  Unless you are
going to say you aren't using udev either?

> Also, if you say S3/S4 are PC oriented (or intel specific; It is
> mentioned in ACPI spec.) terms, the suspend-to-ram and to disk is not
> necessarily PC (or intel) oriented. 

Yeah, "suspend-to-ram" and disk are not pc oriented, but that is not
what you called your kevents, so why mention that?

thanks,

greg k-h

Power event notification patch

[V, Sankara Narayanan]

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

Hi Folks,

 

Here is a simple patch for power event notification to user-space
applications. Basically, what it does is notify the user-space
applications that the system is going to a low power state
(Suspend-to-RAM and Suspend-to-Disk) and resume from that state. This is
useful for the user-space applications to do some significant action
when the system goes to the low power state (like saving an unsaved
file). The user-space objects can form a netlink socket and listen to
these events. It is done through a kobject-netlink socket. For this I
have used the kobject_uevent system call, posting the notification to
user space with standby, hibernate and resume in the action parameter of
the kobject_uevent call (mapped to KOBJ_S3, KOBJ_S4 and KOBJ_RESUME
enums). Appreciate your comments on the patch.

 

Thanks,

Sankara Narayanan V.

 


[-- Attachment #1.2: Type: text/html, Size: 3733 bytes --]

[-- Attachment #2: pwr-evnt-notfn.patch --]
[-- Type: application/octet-stream, Size: 3444 bytes --]

diff -aruN kernel-mid/.gitignore linux-pwr-evnt-notfn/.gitignore
--- kernel-mid/.gitignore	1970-01-01 05:30:00.000000000 +0530
+++ linux-pwr-evnt-notfn/.gitignore	2007-07-05 15:17:02.000000000 +0530
@@ -0,0 +1,47 @@
+#
+# NOTE! Don't add files that are generated in specific
+# subdirectories here. Add them in the ".gitignore" file
+# in that subdirectory instead.
+#
+# Normal rules
+#
+.*
+*.o
+*.a
+*.s
+*.ko
+*.so
+*.mod.c
+*.i
+*.lst
+*.symtypes
+
+#
+# Top-level generic files
+#
+tags
+TAGS
+vmlinux*
+System.map
+Module.symvers
+
+#
+# Generated include files
+#
+include/asm
+include/asm-*/asm-offsets.h
+include/config
+include/linux/autoconf.h
+include/linux/compile.h
+include/linux/version.h
+include/linux/utsrelease.h
+
+# stgit generated dirs
+patches-*
+
+# quilt's files
+patches
+series
+
+# cscope files
+cscope.*
diff -aruN kernel-mid/include/linux/kobject.h linux-pwr-evnt-notfn/include/linux/kobject.h
--- kernel-mid/include/linux/kobject.h	2007-04-16 05:20:57.000000000 +0530
+++ linux-pwr-evnt-notfn/include/linux/kobject.h	2007-07-05 15:17:11.000000000 +0530
@@ -48,6 +48,9 @@
 	KOBJ_OFFLINE	= (__force kobject_action_t) 0x06,	/* device offline */
 	KOBJ_ONLINE	= (__force kobject_action_t) 0x07,	/* device online */
 	KOBJ_MOVE	= (__force kobject_action_t) 0x08,	/* device move */
+	KOBJ_S3		= (__force kobject_action_t) 0x09,	/* system suspend to RAM */
+	KOBJ_S4		= (__force kobject_action_t) 0x0A,	/* system suspend to disk */
+	KOBJ_RESUME	= (__force kobject_action_t) 0x0B,	/* system resume */
 };
 
 struct kobject {
diff -aruN kernel-mid/kernel/power/disk.c linux-pwr-evnt-notfn/kernel/power/disk.c
--- kernel-mid/kernel/power/disk.c	2007-04-16 05:20:57.000000000 +0530
+++ linux-pwr-evnt-notfn/kernel/power/disk.c	2007-07-05 15:17:04.000000000 +0530
@@ -184,6 +184,7 @@
 	resume_console();
  Thaw:
 	unprepare_processes();
+	kobject_uevent(&power_subsys.kset.kobj, KOBJ_RESUME);
 	return error;
 }
 
diff -aruN kernel-mid/kernel/power/main.c linux-pwr-evnt-notfn/kernel/power/main.c
--- kernel-mid/kernel/power/main.c	2007-04-16 05:20:57.000000000 +0530
+++ linux-pwr-evnt-notfn/kernel/power/main.c	2007-07-05 15:17:04.000000000 +0530
@@ -141,6 +141,7 @@
 
 static void suspend_finish(suspend_state_t state)
 {
+	kobject_uevent(&power_subsys.kset.kobj, KOBJ_RESUME);
 	enable_nonboot_cpus();
 	pm_finish(state);
 	device_resume();
@@ -191,6 +192,11 @@
 {
 	int error;
 
+	if (state == PM_SUSPEND_MEM) /* if suspend to RAM */
+		kobject_uevent(&power_subsys.kset.kobj, KOBJ_S3);
+	if (state == PM_SUSPEND_DISK) /* if suspend to disk */
+		kobject_uevent(&power_subsys.kset.kobj, KOBJ_S4);
+
 	if (!valid_state(state))
 		return -ENODEV;
 	if (!mutex_trylock(&pm_mutex))
@@ -335,8 +341,10 @@
 static int __init pm_init(void)
 {
 	int error = subsystem_register(&power_subsys);
-	if (!error)
+	if (!error) {
+		kset_set_kset_s(&power_subsys, power_subsys);
 		error = sysfs_create_group(&power_subsys.kset.kobj,&attr_group);
+	}
 	return error;
 }
 
diff -aruN kernel-mid/lib/kobject_uevent.c linux-pwr-evnt-notfn/lib/kobject_uevent.c
--- kernel-mid/lib/kobject_uevent.c	2007-04-16 05:20:57.000000000 +0530
+++ linux-pwr-evnt-notfn/lib/kobject_uevent.c	2007-07-05 15:15:14.000000000 +0530
@@ -52,6 +52,12 @@
 		return "online";
 	case KOBJ_MOVE:
 		return "move";
+	case KOBJ_S3:
+		return "standby";
+	case KOBJ_S4:
+		return "hibernate";
+	case KOBJ_RESUME:
+		return "resume";
 	default:
 		return NULL;
 	}

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