Behavior of 'UEventd' in Android

[Durgadoss Ramanathan]

Hi,

I have a driver that sends a UEvent [1] on its resume call back.
I want the 'ueventd' to catch this event, and act upon this.

My doubt is whether ueventd be already running when my driver's resume method is
being invoked .

In other words,
when exactly does the ueventd start running once the android phone 'resumes' from 'suspend' ?

[1] kobject_uevent(&dev->kobj, KOBJ_ADD)

--
Regards
Durgadoss

[Emeric VIGIER]

Suspend routine runs in this order:

1. freeze processes

2. suspend drivers

3. turn off CPU

Resume routine is the opposite:

1. turn on CPU

2. resume drivers

3. wake up processes

Sorting the actions differently would most probably cause system crash:

- what would drivers do without the CPU?

- How would userspace process access hardware without the drivers?

So you can assume ueventd is woken up after your driver is resumed.

Also you can verify that by turning on logs in ueventd, kernel/power/suspend.c and adding no_console_suspend to your kernel command line. 

Emeric

--
--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel
---
You received this message because you are subscribed to the Google Groups "Android Linux Kernel Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-kerne...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shankar Brahadeeswaran]

Hi,

>> My doubt is whether ueventd be already running when my driver's resume
>> method is
>> being invoked .

I'm not sure what you mean by this ... if its a Uniprocessor system
any way only one context can execute at a time. So when your resume
code is being exectued, nothing else would be running. The udev daemon
would have executed some sort of "read" system call in the netlink
socket (the uevents are sent to the userland via netlink sockets).
When your driver or any other driver sends a uevent, eventually it
gets added into this socket which will bring the daemon to "run"
state. Whenever it gets a chance to execute it would pickup the event
from the socket and process it.

- Shankar

On Mon, May 13, 2013 at 7:19 PM, Bright Yang
<brigh...@fairchildsemi.com> wrote:
> If you can't sure whether ueventd will catch the event, why not use a delay
> work do send this UEVENT?