The generation of hot plug event in Linux is how to inform the user space, kobject_uevent_env uevent "Turn"

transferred from: http://blog.csdn.net/myarrow/article/details/82598881. Kobject, Ktype, Kset

1) Kobject: Represents the directory in the SYSFS.

2) Ktype: Represents the type of Kobject, mainly contains the release function and attr read and write functions. For example, all buses have the same bus_type, and all classes have the same class_type.

3) Kset: Contains the subsystem concept, Kset itself is a kobject, so it contains a Kobject object. In addition, Kset contains a kset_uevent_ops, which defines three functions

Int (*filter) (struct kset *kset, struct kobject *kobj);

const char * (*name) (struct kset *kset, struct kobject *kobj);

Int (*uevent) (struct kset *kset, struct kobject *kobj, struct kobj_uevent_env *env);

All three of these functions are related to uevent. Filter is used to determine if the uevent is going to be emitted. Name is used to get the name of subsystem. The uevent is used to populate the ENV variable.

2. Uevent Kernel part

Uevent is a message that SYSFS sends to the user space. For example, in the Device_add function, Kobject_uevent (&dev->kobj, Kobj_add) is called; Here Kobj is the event that sends the message kobj,kobj_add is emitted. The Uevent event is defined in Kobject_action:

Enum Kobject_action {

Kobj_add,

Kobj_remove,

Kobj_change,

Kobj_move,

Kobj_online,

Kobj_offline,

Kobj_max

};

int kobject_uevent (struct kobject *kobj, enum kobject_action action)

{

Return Kobject_uevent_env (Kobj, Action, NULL);

}

• Kobject_uevent_env:

The parent of Kobject is looked up until a kobject contains kset is found.

If there is a filter function in Kset, call the filter function to see if you need to filter the uevent message.

If there is a name function in Kset, call the name function to get subsystem name; otherwise, subsystem's name is Kobject name in Kset.

Assign a kobj_uevent_env and start populating the ENV environment variable:

Add environment variable Action=<action name>

Add environment variable Devpath=<kobj ' s path>

Add environment variable Subsystem=<subsystem name>

Increase the environment variable kobject_uevent_env parameter envp_ext the specified environment variable.

Call Kset's uevent function, which will continue to populate the environment variable.

Add the environment variable seqnum=<seq>, where seq is a static variable, each time it accumulates.

Call NetLink to send a uevent message.

Call Uevent_helper, which is eventually converted to a call to user space Sbin/mdev.

3. Uevent User Space Section

Uevent has two user space programs, one is Udev, and the other is Mdev.

Udev listens to uevent messages through NetLink, which can accomplish two functions:

1. Auto Load Module

2. Add and remove device nodes under the Dev directory based on the uevent message.

The other is that Mdev,mdev can be found in the BusyBox code package, which is called by the Uevent_helper function mentioned in the previous section.

The following is a brief introduction to Udev's Module auto-loading process:

The ETC directory has a uevent rule file/etc/udev/rules.d/50-udev.rules

After the Udev program receives the uevent message, it matches in this rule file, and if the match succeeds, the shell command that matches the definition is executed. For example, there is a line in the rule file:

action== "Add", subsystem== "? *", env{modalias}== "? *", run+= "/sbin/modprobe $env {Modalias}"

So, when you receive the Add event for uevent, the shell can automatically load the module defined in Modalias.

The Mdev module auto-loading process is similar to that of its configuration file in/etc/mdev.conf. For example:

$MODALIAS =.* 0:0 660 @modprobe "$MODALIAS"

This rule refers to the module that loads the Modalias representative when the received environment variable contains modalias.

A detailed description of the Mdev is in the docs/mdev.txt of BusyBox.

4. Application of uevent in device driving model

In the SYS directory there is a subdirectory devices, which represents a kset.

When you create a device, the Device_initialize function that is called, by default, sets Kset to Devices_kset, which is the kset represented by the devices subdirectory.

The uevent operation set Device_uevent_ops is set in Devices_kset.

static struct Kset_uevent_ops Device_uevent_ops = {

. Filter = Dev_uevent_filter,

. Name = Dev_uevent_name,

. uevent = Dev_uevent,

};

Dev_uevent_filter, the main rule is to send Uevent,dev must have a class or bus.

Dev_uevent_name, returns the name of the class or bus for Dev.

Dev_uevent function:

If Dev has a device number, add the environment variable major and minor.

If Dev->type has a value, set devtype=<dev->type->name>.

If Dev->driver, set driver=<dev->driver->name>.

If there is a bus, call the bus's uevent function.

If there is a class, call the class's uevent function.

If there is dev->type, call the Dev->type->uevent function.

Normally in bus's uevent function, the MODALIAS environment variable is added and set to the dev name. In this way, Uevent is uploaded to the user space and the module can be automatically loaded by matching the Modalias. Such bus examples are platform and i²c and so on.

Transferred from: http://blog.csdn.net/bingqingsuimeng/article/details/7924473

How the generation of hot plug events in Linux is notified to user space, kobject_uevent_env uevent "Go"