linux--kernel uevent event mechanism and input subsystem __linux

2015-06-05 17:05 7011 People read comments (0) Collection Report This article has been included in: operating system Knowledge BaseCategory: Linux kernels (25)

Directory (?) [+] I. Mechanism of uevent

1. Summary of Prerequisites

(1) Sysfs file system

The main module of the kernel device model and the related part that can be seen between users is the Sysfs file system. The kernel registers the Sysfs file system when it starts, and starts at the beginning of the system. Mounts the Sysfs file system to the/sys mount point through the Mount command.

Mount-t Sysfs Sysfs/sys

So what is the function of the Sysfs file system? In summary, there are three points:

1, the establishment of the system bus, drive, equipment, the bridge between the three

2, like the user space to display the topology of various devices in the kernel Figure 3, provide users with the space for the device to obtain information and operation of the interface, partially replace the IOCTL function.

(2) Kobject:sysfs file system is the most basic structure is kobject,kobject can represent a device, a bus and so on. The SYS directory is visually represented as a directory.

(3) Uevent mechanism

The above analysis is simply a basic understanding of the Linux device model. The role of a go-between, if you want to understand carefully, you need to read the code. With the above for the SYSFS Foundation. Next we will have a more detailed understanding of the uevent mechanism.

What is the uevent mechanism. This has to start with the hot-swappable device. The simplest example is a U disk. When we plug a U disk on the computer, the USB hub of the system detects USB disk device access, and completes the device enumeration process (reading the appropriate device information from the device) and creates the corresponding device structure in the kernel. However, USB devices are thousands of states, and the kernel cannot advance all USB device drivers into memory. When inserting a U disk device, the kernel does not necessarily have a USB drive corresponding to the device. This time the USB drive may be stored in the form of a module on the hard drive.           Load drive must only be from the user state, then what should be done at this time. See here, some people will think, manual typing command load drive, hehe. This is necessarily a method, but it is an ancient method. Linux has designed a uevent mechanism for similar situations. When a new device is added, send the message of the device to the user state. And the user state has a udev process that listens to this information. After receiving the information to do a certain resolution, according to the results of the resolution and the user program configuration to do some processing, including loading the driver.

2. Specific introduction (http://www.wowotech.net/linux_kenrel/uevent.html)

Uevent is a part of the kobject that notifies the user of a space program when a kobject state changes, such as an increase or removal.

When the user space program receives such an event, it will handle it accordingly.

This mechanism is typically used to support hot-plug devices, for example, USB disk-related driver software will dynamically create the device structure (including the corresponding kobject), and inform the user of the space program, for the U disk dynamically create/dev/directory under the device node,

Further, you can notify other applications, the U disk device mount to the system, so that the dynamic support of the device. The position of uevent in kernel

It can be concluded that the uevent mechanism is relatively simple, and the interface provided by Uevent is triggered when any device in the device model has an event to escalate. After the Uevent module is ready to escalate the event format.

The event can be escalated to user space in two ways: one is through the Kmod module, direct call user space executable file;

The other is to pass the event from kernel space to user space through NetLink communication mechanism.

Note 1: The Kmod and NetLink are described in other articles, so this article is no longer explained in detail. internal logic analysis of Uevent

Uevent's code is relatively simple, mainly involving kobject.h and kobject_uevent.c two files, as follows: Include/linux/kobject.h lib/kobject_uevent.c

As mentioned earlier, when using Kmod to escalate event events to user space, the executable file for user space is executed directly. In Linux systems, the execution of executable files relies on environment variables, so kobj_uevent_env is used to organize the environment variables when the event is escalated.

Description: How to specify the user space program for processing uevent (uevent helper).

The above describes the internal action of kobject_uevent_env, it is mentioned that uevent module through the Kmod escalation uevent, through the Call_usermodehelper function, invoke user space executable file (or script, abbreviation uevent Helper) to handle the event. The path to the uevent helper is stored in the Uevent_helper array.

You can statically specify the uevent HELPER when compiling the kernel by Config_uevent_helper_path configuration entries. This approach, however, fork a process for each event, and as the number of devices supported by the kernel increases, this approach will be fatal at system startup (which can result in a memory overflow, etc.). Therefore, this approach is used only in earlier kernel versions, and is now deprecated by the kernel. So when the kernel compiles, the configuration item needs to be left blank.

After the system starts, most of the devices have been ready, and you can reassign a uevent helper as needed to detect hot-plug events during the system's operation. This can be done by writing the helper's path to the "/sys/kernel/uevent_helper" file. In fact, the kernel in the form of SYSFS file system, the Uevent_helper array open to user space for user space programs to modify access, specific reference to "./kernel/ksysfs.c" in the corresponding code, this is no longer described in detail.

3. Case analysis (http://blog.csdn.net/sunweizhong1024/article/details/7928530)analysis of headphone_event escalation events

This article explains the whole process of reporting an event function to the upper level when inserting headphone

#ifdef Config_i_love_pbj30

void headphone_event (int State)

{

Switch_set_state (&wired_switch_dev, state);

}

EXPORT_SYMBOL_GPL (headphone_event);

#endif

The Headphone_event function calls the Switch_set_state function to escalate the event

The KOBJECT_UEVENT_ENV function is then invoked to escalate the event.

The final call to Add_uevent_var () adds the parameters required by the user space to the environment variable, as

retval = Add_uevent_var (env, "action=%s", action_string);

if (retval)

Goto Exit;

retval = Add_uevent_var (env, "devpath=%s", DEVPATH);

if (retval)

Goto Exit;

retval = Add_uevent_var (env, "subsystem=%s", subsystem);

if (retval)

Goto Exit;

4. Case Analysis 2

Uevent is a way for the kernel to notify Android of state changes, such as USB cable insertion, pull-out, battery change, and so on. The essence is that the kernel sends (through the socket) a string, and the application layer (Android) receives and interprets the string to obtain the appropriate information.

(i), kernel side: The uevent is initiated at the kernel end, mainly through functions

Intkobject_uevent_env (struct kobject*kobj, enum kobject_action action,char*envp_ext[])

The main function of this function is to combine a string based on parameters and send it. A typical string is as follows:change@/devices/platform/msm-battery/power_supply/usb vast ACTION=change vast DEVPATH =/devices/platform/msm-battery/power_supply/usb Vast subsystem=power_supply vast power_supply_name= USB vast power_supply_online=0 vast seqnum= 1486 vast

The above piece comes from the Internet, this paragraph whether has the question, wait for the exquisite.

Look at this function: int kobject_uevent_env (Structkobject *kobj, enum kobject_action Action,char *envp_ext[])

static const char *kobject_actions[] ={

[Kobj_add] = "ADD",

[Kobj_remove] = "REMOVE",

[Kobj_change] = "Change",

[Kobj_move] = "Move",

[Kobj_online] = "ONLINE",

[Kobj_offline] = "OFFLINE",

};

The above is the Kobject standard action, the call needs to pass the corresponding enum value

Here's how to get subsystem information

if (uevent_ops&&uevent_ops->name)

subsystem =uevent_ops->name (Kset, kobj);

Else

subsystem =kobject_name (&kset->kobj);

if (!subsystem) {

Pr_debug ("Kobject: '%s ' (%p):%s:unset subsystem caused the"

"Event to Drop!\n", Kobject_name (Kobj), Kobj,

__FUNC__);

return 0;

}

The information data to be passed is prepared below

retval = Add_uevent_var (env, "action=%s", action_string);

if (retval)

Goto exit;

retval = Add_uevent_var (env, "devpath=%s", DEVPATH);

if (retval)

Goto exit;

retval = Add_uevent_var (env, "subsystem=%s", subsystem);

if (retval)

Goto exit;

Envp_ext[i] is a passed in parameter, for some custom information that is carried during the event

if (Envp_ext) {

for (i = 0; envp_ext[i]; i++) {

retval = Add_uevent_var (env, "%s", Envp_ext[i]);

if (retval)

Goto exit;

The following data is sent out via a network socket

Mutex_lock (&uevent_sock_mutex);

List_for_each_entry (ue_sk,&uevent_sock_list, list) {

struct sock *uevent_sock =ue_sk->sk;

struct SK_BUFF*SKB;

size_t Len;

NETLINK_CB (SKB). Dst_group =1;//Start sending data below

retval =netlink_broadcast_filtered (Uevent_sock, SKB,

0, 1, Gfp_kernel,

Kobj_bcast_filter,

Kobj);

}

(b), Android side:

Private Finalueventobserver Mueventobserver = Newueventobserver () {

@Override

public void Onuevent (ueventobserver.ueventevent) {

if (DEBUG) slog.v (TAG, "USB uevent:" + event.tostring ());

String State =event.get ("Usb_state");

String accessory =event.get ("accessory");

Added for USB develpment Debug, more logfor more debuging help

if (DEBUG) LOG.W (TAG, "mUEventObserver:onUEvent:state =" + state);

Added for USB develpment Debug, more logfor more debuging help

if (state!= null) {

Mhandler.updatestate (state);

}else if ("START". Equals (Accessory)) {

if (DEBUG) slog.d (TAG, "Got accessory start");

Setcurrentfunction (Usbmanager.usb_function_accessory,false);

}

}

};

/////invokes the following action when the class is initialized, initiating the listening action.

Mueventobserver.startobserving (Usb_state_match);

////will eventually invoke the Addobserver to Ueventobserver:

privatearraylist<object> mobservers = newarraylist<object> ();

Public Voidaddobserver (String match, Ueventobserver observer) {

Synchronized (mobservers) {

Mobservers.add (match);

MOBSERVERS.ADD (Observer);

}

}

private static final String Usb_state_match =

"DEVPATH=/DEVICES/VIRTUAL/ANDROID_USB/ANDROID0";

The function eventually adds "DEVPATH=/DEVICES/VIRTUAL/ANDROID_USB/ANDROID0" to the matching sequence, and when kernel sends the data with that string, it returns a matching success. Then call the Mueventobserver onuevent function;

Ueventobserver.java

private static class Ueventthread Extendsthread {

privatearraylist<object> mobservers = newarraylist<object> ();