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@xxxxxxxxx] Sent: Thursday, July 05, 2007 6:51 PM To: V, Sankara Narayanan Cc: johannes@xxxxxxxxxxxxxxxx; Oliver Neukum; linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx Subject: RE: 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@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
