Linux device models

An important feature of linux kernel is the provision of a unified kernel device model. With the continuous advancement of technology, the topology structure of the system becomes more and more complex, and the requirements for smart power management, hot swapping, and plugandplay support are also increasing, making it difficult to use 2.4 cores... an important feature of the linux 2.6 kernel is the provision of a unified kernel device model. With the continuous advancement of technology, the topology structure of the system becomes more and more complex, and the requirements for intelligent power management, hot swapping, and support for plug and play are also increasing. The 2.4 kernel is hard to meet these requirements. To meet the needs of this situation, the 2.6 kernel has developed a new device model. 1. sysfs is a special file system similar to the proc file system. it organizes devices in the system into hierarchies and provides detailed kernel data structure information to user mode programs. The top-level directory mainly includes: Block Directory: including all Block Devices Directory: including all the Devices in the system, and organized into a hierarchical Bus directory according to the Bus type mounted to the device: include all bus types in the system Drivers Directory: including all registered device Drivers in the kernel Class Directory: the device types in the system (such as Nic devices, sound card devices, etc.) 2. kernel object mechanism key data structure www.2cto.com 2.1 kobject kernel object Kobject is a new device management mechanism introduced by Linux 2.6, represented by struct kobject in the kernel. Through this data structure, all devices have a unified interface at the underlying layer. kobject provides basic object management, which is the core structure of the Linux 2.6 device model. it is closely associated with the sysfs file system, each kobject object registered in the kernel corresponds to a directory in the sysfs file system. The Kobject structure is defined as: struct kobject {char * k_name; pointer to the device name char name [KOBJ_NAME_LEN]; device name struct kref; object reference count struct list_head entry; struct kobject * parent mounted to the unit in the kset; pointer to the parent object struct kset * kset; pointer to the kset struct kobj_type * ktype; the pointer to the object type descriptor struct dentry * dentry; the path pointer to the file node corresponding to the object in the sysfs file system}; the kref field indicates the reference count of the object, the kernel uses kref to manage the object reference count. the kernel provides two functions, kobject_get () and kobject_put (), to increase and decrease the reference count respectively. when the reference count is 0, all Resources will be released. The Ktype field is a pointer to the kobj_type structure, indicating the type of the object. The Kobj_type data structure contains three fields: a release method is used to release resources occupied by kobject; a sysfs_ops pointer points to the sysfs operation table and a default attribute list of sysfs file systems. The Sysfs operation table includes two functions: store () and show (). When the user state reads the attribute, the show () function is called. the Function Code specifies that the attribute value is stored in the buffer and returned to the user state. The store () function is used to store the attribute value passed in the user state. 2.2 kset kernel object set Kobject is usually organized into a hierarchical structure through kset. kset is a set of kobject of the same type. it is expressed in the kernel using the kset data structure and is defined: struct kset {struct subsystem * subsys; pointer to the subsystem struct kobj_type * ktype; pointer to the struct list_head list of the kset object type descriptor; used to connect the chain table headers of all kobject in the kset, struct kobject kobj; embedded kobjectstruct kset_hotplug_ops * hotplug_ops; pointer to hot swappable operation table }; all the kobject contained in the kset is organized into a bidirectional cyclic linked list. the list Field is the header of the linked list. The Ktype field points to a kobj_type structure, which is shared by all the kobject in the kset, indicating the type of these objects. The Kset data structure is also embedded with a kobject object (represented by the kobj domain). The parent fields of all the kobject objects belonging to this kset point to this embedded object. In addition, kset depends on kobj to maintain reference count: kset reference count is actually the reference count of the embedded kobject object. 2.3 The subsystem kernel object Subsystem subsystem is a collection of ksets that describe a type of device subsystems in the system. for example, block_subsys indicates all block devices and corresponds to the block directory in the sysfs file system. Similarly, devices_subsys corresponds to the devices directory in sysfs and describes all devices in the system. The Subsystem is described by the data structure of struct subsystem and is defined as: struct subsystem {struct kset; embedded kset object struct rw_semaphore rwsem; mutex access semaphore}; each kset must belong to a subsystem, you can add a kset to the subsystem by setting the subsys field in the kset structure to point to the specified subsystem. All ksets attached to the same subsystem share the same rwsem semaphore, which is used to synchronously access the linked list in the kset. 3. the kernel object mechanism mainly involves functions targeting different levels of data structures of kernel objects. linux 2.6 kernel defines a series of operation functions, which are defined in the lib/kobject. c file. Www.2cto.com 3.1 kobject related function void kobject_init (struct kobject * kobj); kobject initialization function. Set the reference count of kobject to 1, the entry field to itself, and the kset reference count to which it belongs plus 1. Int kobject_set_name (struct kobject * kobj, const char * format,...); set the name of the specified kobject. Void kobject_cleanup (struct kobject * kobj) and void kobject_release (struct kref * kref); kobject clearing function. When its reference count is 0, the resources occupied by the released object are released. Struct kobject * kobject_get (struct kobject * kobj); adds the reference count of the kobj object to 1 and returns the pointer of the object. Void kobject_put (struct kobject * kobj); subtract 1 from the reference count of the kobj object. if the reference count is reduced to 0, call kobject_release () to release the kobject object. Int kobject_add (struct kobject * kobj); adds the kobj object to the Linux device level. Mount the kobject object to the list chain of the kset, increase the reference count of kobject at all levels in the parent directory, create a file node under the Directory to which the parent points, and start the hotplug function of the kernel object of this type. Int kobject_register (struct kobject * kobj); kobject registers a function. Call kobject_init () to initialize kobj, and then call kobject_add () to register the kernel object. Void kobject_del (struct kobject * kobj); delete the kobj object from the Linux device level (hierarchy. Void kobject_unregister (struct kobject * kobj); kobject deregister the function. Unlike kobject_register (), it first calls kobject_del to delete the object from the device level, and then calls kobject_put () to reduce the reference count of the object. if the reference count is reduced to 0, then the kobject object is released. 3.2 kset functions are similar to kobject. kset_init () initializes the specified kset, and kset_get () and kset_put () increase and decrease the reference count of kset objects respectively. The Kset_add () and kset_del () functions add the specified keset object to the device level and delete it from the device level respectively. the kset_register () function completes kset registration and kset_unregister () the function is used to cancel the kset operation. 3.3 subsystem-related functions subsystem a group of similar functions are completed: void subsystem_init (struct subsystem * subsys); int subsystem_register (struct subsystem * subsys ); void subsystem_unregister (struct subsystem * subsys); struct subsystem * subsys_get (struct subsystem * subsys) void subsys_put (struct subsystem * subsys); 4. the device model component is based on the above kernel object mechanism. The Linux device model is based on several key components. The following describes these components in detail. 4.1 any device in the devices system is described by a device object in the device model. The data structure struct device is defined as: struct device {struct list_head g_list; struct list_head node; struct list_head bus_list; struct list_head driver_list; struct list_head children; struct device * parent; struct kobject kobj; char bus_id [BUS_ID_SIZE]; struct bus_type * bus; struct device_driver * driver; void * driver_data;/* Several fields omitted */}; g_list mounts the device object In the global device linked list, all device objects are included in devices_subsys and organized into hierarchies. The Node domain mounts the object to the linked list of its brother object, while the bus_list is used to organize the devices connected to the same bus into a linked list, driver_list organizes all devices managed by the same driver into a chain table. In addition, the children Field points to the sub-object linked list header of the device object, and the parent field points to the parent object. The Device object is also embedded with a kobject object, which is used to reference counting management and implement the Device hierarchy. The Driver domain points to the Driver object that manages the device, while driver_data is the data provided to the Driver. The Bus Field describes the type of the Bus to which the slave node is connected. The kernel provides functions to operate device objects. The Device_register () function inserts a new device object into the device model and automatically creates a corresponding directory under/sys/devices. Device_unregister () to cancel the device object. Get_device () and put_device () increase and decrease the reference count of the device object respectively. Generally, the device structure is not used independently, but included in a larger structure as a sub-structure. for example, the struct pci_dev describing the PCI device, where the dev field is a device object. Each driver in the www.2cto.com 4.2 drivers system is described by a device_driver object. the corresponding data structure is defined as: struct device_driver {char * name; the device driver name is struct bus_type * bus; the bus type struct kobject kobj attached to the device managed by the driver; built-in kobject object struct list_head devices; int (* probe) of the device linked list header managed by the driver) (struct device * dev); points to the device detection function, used to detect whether the device can be managed by the driver int (* remove) (struct device * dev ); the function used to delete the device/* some fields omitted */}. similar to the device structure, the device_driver object relies on the embedded kobject object to implement reference calculation. Number management and hierarchical organization. The kernel provides similar functions to operate the device_driver object, such as get_driver () to increase the reference count, and driver_register () to insert a new driver pair to the device model, create a directory in the sysfs file system. The Device_driver () structure also includes several functions for hot plugging, plug-and-play, and power management events. 4.3 in the buses system, the bus is described by struct bus_type and defined as: struct bus_type {char * name; the name of the bus type struct subsystem subsys; the subsystemstruct kset drivers related to the bus; struct kset devices, a collection of drivers related to the bus, struct bus_attribute * bus_attrs, and struct device_attribute * dev_attrs; device attributes struct driver_attribute * drv_attrs; driver attributes int (* match) (struct device * dev, struct device_driver * drv); int (* hotplug) (struct device * Dev, char ** envp, int num_envp, char * buffer, int buffer_size); int (* suspend) (struct device * dev, u32 state); int (* resume) (struct device * dev) ;}; each bus_type object is embedded with a subsystem object, which is a subsystem object of all bus types in the bus_subsys object management system. Each bus_type object corresponds to a sub-directory under the/sys/bus Directory. for example, the PCI bus type corresponds to/sys/bus/pci. There are two sub-directories in each of these directories: devices and drivers (corresponding to the devices and drivers fields in the bus_type structure respectively ). The devices subdirectory describes all devices connected to the bus, and the drivers Directory describes all drivers associated with the bus. Similar to the device_driver object, the bus_type structure also contains several functions (such as match () and hotplug () to handle hot swapping, plug and play, and power management events. 4.4 The Device class in the classes system is described by struct class, indicating a certain type of device. All class objects belong to the class_subsys subsystem and correspond to the/sys/class directory in the sysfs file system. Each class object includes a class_device linked list. each class_device object represents a logical device and is associated with a physical device through the dev field (a pointer to the struct device) in the struct class_device. In this way, a logical device always corresponds to one physical device, but a physical device may correspond to multiple logical devices. In addition, the class structure includes functions used to handle hot swapping, plug and play, and power management events, similar to the device object and driver object. The device modeldevice model has three main data structures: kobject, kset, and subsystem. related data structure: struct kobject {char * k_name; char name [KOBJ_NAME_LEN]; struct kref; struct list_head entry; struct kobject * parent; struct kset * kset; struct kobj_type * ktype; struct dentry * dentry;}; struct kset {struct subsystem * subsys; struct kobj_type * ktype; struct list_head list; spinlock_t list_lock; struct kobject kobj; Struct kset_hotplug_ops * hotplug_ops;}; www.2cto.com struct subsystem {struct kset; struct rw_semaphore rwsem;}; they are the skeleton of the entire device model (in an object-oriented tone: this is called the base class (not the chicken ribs ^ _')). All other structures, such as cdev and bus, are built on these frameworks. Kobject is the most basic. Many structures have an embedded reference counting function of kobject. kobject, which is the most important. Kset can be considered as a set of kojbect, while subsystem can be considered as a set of several ksets. Multiple ksets can point to a subsystem through the subsys pointer. However, the subsystem only contains an embedded kset. This unidirectional relationship means that it is impossible to find all the ksets of the subsystem through a subsystem struct. Their contact information is as follows: /strong> kset <STRONG/| + ------------ + | subsys | + ------------ + | ktype | + ------------ + |/-----------------------> | list | <------------------------/| + ------------ + |/----> | kobj | <---/| + ------------ + | hotplug_ops | | + ------------ + | | Kobject | + -------- + | + -------- + | parent | ----- // ----- | parent | + -------- + |/----> | entry | <---------------------------------> | entry | -----/| + -------- + | + -------- + |/--------- | kset | ------- --/+ -------- ++ -------- + | + -------- ++ -------- + Note that the list in kset is a two-way linked list that runs through all kobject, however, it is not necessarily worn together through the entry field of kobject. All kobject is not simply an independent kobject, but it may be a kobject embedded in other data structures (such as kset and subsystem) subsystem <-----/+ ---------------------- + | kset | + ------------- + | subsys | -------/| + ------------- + | ktype | kset + ------------- + | | list | + ------------- + | kobj | + ------------- + | hotplug_ops | www.2cto.com | + ------------- + | others | rwsem | | + --- --------------------- + All ksets must belong to a subsystem (the subsys of the kset points to a subsystem). For the kset embedded in the subsystem, if its subsys is not set, it points to its own subsystem. (See subsystem_register () function) by Tommy_wxie