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

[Daniel Borkmann <danborkmann@googlemail.com>]

[-- Attachment #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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]