First glance at the Linux Device Driver Model and sysfs (1)

1. What is sysfs?
"Sysfs is a ram-based filesystem initially based on ramfs. It provides a means
To export kernel data structures, their attributes, and the linkages between them to userspace. "--sysfs.txt
A virtual memory-based File System,
In addition to the same features as proc, which have the ability to view and set kernel parameters, it is more important to use the Linux unified device model for management.

The newly designed kernel mechanism should use sysfs as much as possible and retain proc to the pure "process File System ".
The sysfs file system is always mounted on the/sys mount point.

2/sys file system directory
The/sys directory contains blocks, bus, devices, firmware, FS, kernel, module, and power,
These directories demonstrate the kernel's model and method for unified management of various devices.
/Sys/devices
This is a hierarchical Expression Model of the kernel for all devices in the system and the most important directory structure for managing devices in the/sys file system.

/Sys/dev
This directory maintains a symbolic link file that links the primary and secondary numbers (Major: minor) of the device by character to the real device (/sys/devices.

/Sys/Bus
The directory structure of the kernel device is layered by bus type. All devices in devices are connected to a certain bus. The Symbolic Links of each specific device can be found under each specific bus.

/Sys/class
This is a device model categorized by device features. For example, all input devices in the system appear under/sys/class/input, regardless of the bus they connect to the system.

/Sys/block
The current location of all Block devices in the system
(It is said that the kernel 2.6.26 has been officially moved to/sys/class/block. The old interface/sys/block is retained for backward compatibility, however, the content has changed to a symbolic link file pointing to the real devices in/sys/devices/, But it seems wrong)

/Sys/firmware
User space interface of the system's firmware Loading Mechanism

/Sys/fs
All file systems in the system are described as follows, including file systems and mounted files stored by file systems. However, only a few file systems such as fuse and gfs2 support sysfs interfaces, the hierarchical control parameters of some traditional Virtual File Systems (VFS) are still in the sysctl (/proc/sys/Fs) interface;

/Sys/kernel
Here is the location of all the adjustable parameters in the kernel. Currently, only uevent_helper, kexec_loaded, mm, and the New Slab allocator are used, other kernel adjustable parameters are still in the sysctl (/proc/sys/kernel) interface;

/Sys/Module
Information about all modules in the system, whether these modules are compiled into the kernel image file (vmlinuz) in the inlined mode or as an external module (Ko file ), may all appear in/sys/module:

* After being compiled into an external module (Ko file), the corresponding/sys/module/<module_name> /, in addition, some attribute files and attribute directories will appear in this directory to indicate information about the modules, such as the version number, loading status, and provided drivers;
* For a module compiled as an inline mode, the corresponding/sys/module/<module_name> appears only when it has a module parameter with a non-0 attribute, the available parameters of these modules are displayed in/sys/modules/<modname>/parameters/<param_name>,
O For example, The read/write parameter/sys/module/printk/parameters/time controls whether the inline module printk adds a time prefix when printing kernel messages;
O parameters of all inline modules can also be set by "<module_name>. <param_name >=< value> "is written in the kernel startup parameters. For example, add the parameter" printk. time = 1 "is the same as writing 1 to"/sys/module/printk/parameters/Time;
* Inline modules without non-zero attribute parameters do not appear here.

/Sys/power
Here is the power option in the system. There are several attribute files in this directory that can be used to control the power status of the entire machine. For example, you can write control commands to shut down or restart the machine.

Underlying structure kset and kobj of sysfs
The basic structure of the Linux unified device model is as follows:
1 device 2 device drive 3 bus type 4 device category

-Device (devices)
The device is the most basic type in this model. It is organized in layers based on the connection of the device and corresponds to the struct device data structure of the kernel. It is located in/sys/devices
-Device drivers)
Provides driver support for devices and manages drivers. It corresponds to the struct device_driver data structure in the kernel.
-Bus Type (bus types)
All devices connected to this bus are managed at the entire bus level. The kernel struct bus_type data structure is located at/sys/bus/
-Device classes)
This is a device Hierarchy Tree organized by function. For example, the USB interface and the PS/2 interface are input devices, which will appear under/sys/class/input /.
When you add a device driver for one or more devices to the system, you need to define the corresponding bus type (struct bus_type) and device type (struct device ), and call the provided functions for registration (bus_register (), device_register (), initialization, and so on.

The Linux unified device model uses two basic data structures: kset and kobject for tree-based and linked-list structures to organize the above units:

Kobject: the most basic objects in the Linux device model, such as bus, devices, and drivers, are connected through kobject to form a tree structure that corresponds to/sys.
The kobject structure provides basic object management for some big data structures and subsystems, avoiding repeated implementations of similar functions. These functions include
-Object reference count.
-Maintain the object linked list (SET ).
-Object locking.
-Representation in the user space.

struct kobject {
        const char              *name;
        struct list_head        entry;
        struct kobject          *parent;
        struct kset             *kset;
        struct kobj_type        *ktype;
        struct sysfs_dirent     *sd;
        struct kref             kref;
        unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;
        unsigned int state_add_uevent_sent:1;
        unsigned int state_remove_uevent_sent:1;
}; 

Here, struct kref contains a atomic_t type for reference counting. parent is a single pointer to the parent node. Entry is used for the parent kset to maintain the kobject structure as a two-way linked list in the chain table header structure;

Kset: it is used to provide a packaging set for objects of the same type. In the kernel data structure, it is also implemented by embedding a kboject, therefore, it is also a kobject (inheritance relation in the object-oriented OOP concept), with all the functions of kobject;

struct kset {
        struct list_head list;
        spinlock_t list_lock;
        struct kobject kobj;
        struct kset_uevent_ops *uevent_ops;
}; 

The struct list_head list is used to maintain the kobject in the set as a bidirectional linked list by struct list_head entry;

Kset and kobj are mutually contained. kobject is organized into a hierarchical structure through kset. kset is a set of kobject of the same type and is more of a composite relationship, realize the object-oriented idea by means of combination, rather than inheritance. Is that true?

So the question is, why is it necessary to implement such a device driver model through complicated connections ??

References:

Use the/sys file system to access the Linux Kernel
For Linux, I'm sysfs.