Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the underlying architecture and organization of the Linux device driver model". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how the underlying architecture and organization of the Linux device driver model is.

Why is it necessary to have a device driver model? The early kernel (before 2.4) did not have the concept of the device driver model, but it can still be used; but to the 2.6 version officially introduced the device driver model, because there are more and more actual hardware devices, many devices have power requirements and so on.

With some new features, the kernel must have a better and easier-to-use driver system to manage the device, which introduces what we call the device driver model here.

The device driver model is responsible for uniformly implementing and maintaining some features, such as power management, hot plug, object life cycle, user space and driver space interaction (sysfs). The device driver model is designed to simplify drivers.

Programming, managing devices and drivers, but objectively, the design and implementation of the device driver model itself is very complex. In fact, this also confirms a sentence: the easier it is to use, the more complex it is to achieve.

The underlying architecture of the device driver model (1) kobject structure (include\ linux\ kobject.h)

The kobject structure is a structure at the bottom of the device driver model, which is a basic unit of all objects under the device driver model, and it is a common part of abstracting all objects under the device driver model.

The kobject structure provides some common services: object reference counting, maintaining object linked lists, object locking, and representation of user space.

All kinds of objects in the device-driven model will contain a kobject, which is equivalent to the total base class in the object-oriented idea.

(2) element analysis of kobject structure.

1 struct kobject {2 const char * name; / / the name of the object 3 struct list_head entry; / / is used to point to the next kobject structure object in the parallel relationship (it can be understood that multiple files or folders in the same directory are linked to them) 4 struct kobject * parent / / to point to the parent object (that is, the object corresponding to his upper folder) 5 struct kset * kset; / / to point to the kset 6 struct kobj_type * ktype; / / to a kobj_type object 7 struct sysfs_dirent * sd; 8 struct kref kref / / reference count of kobject 9 unsigned int state_initialized:1; / / status flag bit 10 unsigned int state_in_sysfs:1; 11 unsigned int state_add_uevent_sent:1; 12 unsigned int state_remove_uevent_sent:1; 13 unsigned int uevent_suppress:1; 14} whether the object has been initialized (3) element analysis of kset structure (include\ linux\ kobject.h)

1 struct kset {2 struct list_head list; / / used to link all kobject objects in this directory 3 spinlock_t list_lock; / / spin lock 4 struct kobject kobj; / / this kobject is the corresponding object structure of this directory 5 const struct kset_uevent_ops * uevent_ops; 6} From the kset structure, we can see that kobject is actually contained by kset. The main function of kset is to be the container class of the top-level kobject. The main purpose of kset is to change each kobject.

(representing individual objects) organize the directory hierarchy, it can be thought that the purpose of kset is to create directories in sysfs, so that multiple objects in the device driver model can be organized hierarchically and logically.

It can be understood that as long as an object in the form of a folder in sysfs must be contained by kset.

(4) the relationship between kset and kobject

The relationship between kset and kobject: kset is a container of kobject. You can think of kset as a directory, and kobject is the files in this directory. If there are subdirectories in this kset directory, then this

There is a child kset in the directory.

Connections between kset and kobject, kobject and kobject, kset and kset:

(1) connection under parallel relation: it is explained by kobject object An and kset object B.

(1) connection between kobject and kobject: a points to the next structure of the next kobject object through the next pointer in the kobject structure (if An is a chain list trailer, then next

Point to the list_head structure in his upper kset object), through the prev pointer in the list_head structure, to the list_head structure of the previous kobject object (if An is a chain

Table header, then prev points to the list_head structure in his upper kset object.

(2) connection between kset and kobject: B points to the list_head structure of the next kobject object by embedding the next pointer in the list_head structure in the internal kobject structure (if

B is a chain tail, then next points to the list_head structure in his upper kset) and points to the list_head of the previous kobject object through the prev pointer in the list_head structure.

Structure (if B is a chain header, prev points to the list_head structure in his upper kset).

(3) the connection between kset and kset: B points to the list_head in the kobject structure in the next kset by embedding the next pointer in the list_head structure in the internal kobject structure.

Structure (if B is a chain tail, next points to the list_head structure in his upper kset), through the prev pointer in the list_head structure to the

The list_head structure in the kobject structure (if B is a chain header, prev points to the list_head structure in his upper kset).

So it can be seen from the above that the connection of the parallel relation is connected through the list_head structure under the kobject, and the parent class kset is connected to the chain header and footer of all the objects under it through the list_head under kset.

(2) the connection relationship under the superior-subordinate relationship: all kobject objects under the kset container point to the kobject structure in the parent class kset through the parent pointer and to the parent class kset through the kset pointer.

All the parent child containers under the kset container point to the kobject structure in the parent class kset through the parent pointer in the kobject structure below him, and to the parent class kset container through the kset pointer in the kobject structure.

(5) kobj_type structure

Referred to as ktype in many books, each kobject needs to be bound with a ktype to provide the corresponding function.

The key point 1:sysfs_ops, which provides the operation methods (show and store) of the object in sysfs, and the key point 2:attribute, which provides attributes in the form of files in sysfs, is actually the application interface.

(6) the relationship among kset, kobject and kobj_ type.

Organization of bus device driver under device driver Model (1) bus

The bus actually exists physically, and its English name is bus (bus). The function of the bus is to connect the devices at both ends of the bus so that they can communicate (data exchange) through the bus.

The introduction of bus actually borrows the advantages of bus design and forms a corresponding relationship with physical bus, which can manage hardware equipment more conveniently.

(1.1) bus_type structure (include\ linux\ device.h)

Bus_type structure is the structure needed to create a kind of bus in the bus. The actual bus fills the structure to form a specific bus according to its own characteristics and requirements.

1 struct bus_type {2 const char * name; / / bus name 3 struct bus_attribute * bus_attrs; / / attributes of the bus 4 struct device_attribute * dev_attrs; / / attributes of devices under the bus 5 struct driver_attribute * drv_attrs / / attribute of device driver under this bus 6 7 int (* match) (struct device * dev, struct device_driver * drv); / / matching function between device and device driver under this bus 8 int (* uevent) (struct device * dev, struct kobj_uevent_env * env); / / event function hotdial 9 int (* probe) (struct device * dev) / / probe function under the bus 10 int (* remove) (struct device * dev); 11 void (* shutdown) (struct device * dev); 12 13 int (* suspend) (struct device * dev, pm_message_t state); 14 int (* resume) (struct device * dev); 15 16 const struct dev_pm_ops * pm / / 17 18 struct bus_type_private * p related to power management; / / the private data p-> subsys.kobj of the bus represents the corresponding object 19} of the bus in the driver model; for example, the definition of ac97 bus in the kernel: the definition of usb bus

(2) equipment

(2.1) the bus design in the device driver model will include both devices and drivers, for example, for usb buses: usb_device and usb_driver; for platform buses: platform_device and platform_driver

They will contain the corresponding base class devices and base class drivers: struct device and struct device_driver, just as all the objects in the driver model above contain the base class kobject, so for all specific buses

The device structure in contains the base class struct device, and the driver structure contains the base class struct device_driver.

This paragraph is about the struct device structure (include\ linux\ device.h), that is, the device.

(2.2) struct device is the abstraction of hardware devices in the kernel driver framework

(2.3) usually device is not used alone, but is included in a specific device structure, such as struct usb_device. That is, what is mentioned above is included in the device structure under a specific bus.

1 struct device {2 struct device * parent; 3 struct device_private * p; 4 struct kobject kobj; / * contains a kobject structure because it belongs to an object in the device driver model * / 5 const char * init_name; 6 struct device_type * type; 7 struct mutex mutex; 8 struct bus_type * bus; 9 struct device_driver * driver 10 void * platform_data; / * this is a pointer of void type, which is used to point to the unique data structure of this device. The data structure type is defined by itself. The later led driver uses this custom structure to store device information: GPIO, etc., instead of using the resource structure under the bus * / 11 struct dev_pm_info power. 12 13 # ifdef CONFIG_NUMA 14 int numa_node; 15 # endif 16 17 u64 * dma_mask; 18 u64 coherent_dma_mask; 19 struct device_dma_parameters * dma_parms; 20 struct list_head dma_pools; 21 struct dma_coherent_mem * dma_mem; 22 struct dev_archdata archdata; 23 24 # ifdef CONFIG_OF 25 struct device_node * of_node 26 # endif 27 28 dev_t devt; 29 spinlock_t devres_lock; 30 struct list_head devres_head; 31 struct klist_node knode_class; 32 struct class * class; 33 void (* release) (struct device * dev); / * function called when we uninstall the device * / 34}; (3) struct device_driver (include\ linux\ device.h)

As above, struct device_driver is the abstraction of the driver in the kernel driver model, with the following structure: focus on name and probe

(4) Class (class)

The real meaning of class is to act as a container for multiple devices that belong to the same class. In other words, class is a man-made concept that aims to classify and manage all kinds of devices. Of course, class is classifying.

At the same time, some "tags" are affixed to each class, which is the infrastructure that the device driver model provides for us to write drivers. So a device can tell which class it belongs to from the point of view of class, or from the point of view of bus.

Which bus did he hang under?

Mdev (an embedded tool for automatically creating device nodes and device classes) cannot be used without class.

Related structures: struct class (include\ linux\ device.h) and struct class_device.

The relationship between device driver model and device driver framework at the beginning of learning device driver model, it is easy to get confused. I think teachers sometimes mix these two concepts together. I think it is necessary to make a distinction between these two concepts. (the following is purely my own understanding)

(1) scope of applicability: device driver framework is actually for a certain type of hardware devices. Different hardware devices have driver frameworks for their own characteristics. For example, led will have led driver framework, flash will have flash.

Driver framework, you can't use led driver framework on flash hardware devices. As mentioned before, the device driver model is a software system used to manage hardware devices and make driver programming easier, and this system itself is very complex.

There is only one set of system, which is feasible for all hardware devices.

(2) function: the device driver framework is a standard interface written by engineers related to maintenance drivers in the kernel for different hardware devices. They have encapsulated the same attributes of the hardware devices, leaving some interfaces for our specific driver development engineers.

To use, in fact, these standard interfaces are also encapsulated using the interface functions related to writing drivers provided by the original kernel, just to make driver development easier. The device driver model is a set of complex software architecture built and implemented in the kernel.

His role is not only used in the development of drivers, but also in the management of devices and device drivers, but also in response to more and more new features.

(3) it should be noted that we can write a driver without based on the driver model and without using the driver framework. In fact, the driver written at the beginning of learning the driver directly uses the original interface function provided by the kernel to write the driver.

There is no problem with this, and the driver can operate normally, of course, it may be difficult for complex equipment.

Thank you for your reading, the above is the content of "what is the underlying architecture and organization of the Linux device driver model". After the study of this article, I believe you have a deeper understanding of the underlying architecture and organization of the Linux device driver model, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.