Linux Kernel Character Module (Part II)

1. Registering Device Numbers

In the Linux kernel, device numbers are the core identifiers for character devices and block devices, consisting of a major device number and a minor device number. Device number management is fundamental to driver development, and below I will analyze the Linux device number registration mechanism in detail.

1.1 Device Number Structure

typedef u32 dev_t; // 32-bit device number• Major device number: high 12 bits (0-4095), identifies device type/driverMinor device number: low 20 bits (0-1,048,575), identifies specific device instance

#define MAJOR(dev) ((dev) >> 20)        // Extract major device number
#define MINOR(dev) ((dev) & 0xfffff)    // Extract minor device number
#define MKDEV(ma,mi) (((ma) << 20) | (mi)) // Combine device number

1.2 Device Number Registration Methods

Static Registration

Applicable Scenarios: Specify device number when the available device number is known.

int register_chrdev_region(dev_t first, unsigned count, const char *name);

Parameter Description:

• first: Starting device number (generated using MKDEV).
• count: Number of consecutive device numbers.
• name: Device name (displayed in /proc/devices).

Workflow:

1. Check if the device number range is available.
2. Add the device number to the kernel device number mapping table.
3. Create an entry in /proc/devices.

Dynamic Registration

Applicable Scenarios: Automatically allocate, suitable for avoiding device number conflicts.

int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count, const char *name);

Parameter Description:

• dev: Output parameter, returns the allocated device number.
• baseminor: Requested starting minor device number.
• count: Number of device numbers.
• name: Device name.

Allocation Strategy:

1. Attempt to allocate from the range 234-255 (traditional dynamic allocation area).
2. If it fails, try the entire range 1-4095.
3. Use a red-black tree for efficient searching of free device numbers.

2. Kernel Implementation Mechanism

1. Device Number Management Data Structure

struct char_device_struct {
    struct list_head list;    // List node
    dev_t dev;                // Device number
    unsigned int major;       // Major device number
    unsigned int baseminor;   // Starting minor device number
    int minorct;              // Number of minor device numbers
    const char *name;         // Device name
    struct file_operations *fops; // File operations
    struct cdev *cdev;        // Associated cdev structure
};

2. Core Logic of Registration Process

static int __register_chrdev_region(unsigned int major, unsigned int baseminor, int minorct, const char *name) {
    struct char_device_struct *cd;

    // Check device number range validity
    if (major >= CHRDEV_MAJOR_MAX) 
        return -EINVAL;

    // Dynamic allocation: find free major device number
    if (major == 0) {
        for (m = CHRDEV_MAJOR_DYN_END; m > 0; m--) {
            if (!find_chrdev_region(m, baseminor, minorct))
                break;
        }
        // ... allocation logic
    }

    // Create new device entry
    cd = kmalloc(sizeof(*cd), GFP_KERNEL);
    cd->major = major;
    cd->baseminor = baseminor;
    cd->minorct = minorct;
    cd->name = name;

    // Add to global list
    list_add(&amp;cd->list, &amp;chrdevs);
    return 0;
}

3. Device Number Lifecycle Management

1. Registration Phase

dev_t dev;
int ret;

// Static registration
dev = MKDEV(250, 0);
ret = register_chrdev_region(dev, 1, "mydev");

// Dynamic registration
ret = alloc_chrdev_region(&amp;dev, 0, 1, "mydev");
major = MAJOR(dev);
minor = MINOR(dev);

2. Unregistration Phase

void unregister_chrdev_region(dev_t from, unsigned count) {
    struct char_device_struct *cd = find_chrdev_region(from);
    if (cd) {
        // Remove from list
        list_del(&amp;cd->list);
        // Free associated cdev
        if (cd->cdev)
            cdev_del(cd->cdev);
        // Free memory
        kfree(cd);
    }
}

4. Usage Methods

1. Device Number Selection Strategy:

• Static Allocation: Preferably use 240-254 (IANA recommended dynamic allocation area).
• Avoid Using: 0 (special meaning), 1-9 (traditional devices).

2. Error Handling:

ret = register_chrdev_region(dev, 1, "mydev");
if (ret < 0) {
    // EBUSY: Device number already occupied
    // EINVAL: Invalid parameter
    pr_err("Registration failed: %d\n", ret);
    return ret;
}

3. Multi-Device Management:

// Register multiple consecutive device numbers
alloc_chrdev_region(&amp;dev, 0, NUM_DEVICES, "multi_dev");
for (i = 0; i < NUM_DEVICES; i++) {
    cdev_init(&amp;cdev[i], &amp;fops);
    cdev_add(&amp;cdev[i], MKDEV(major, minor + i), 1);
}

Code

#include &lt;linux/init.h&gt;    // Module initialization and exit macros
#include &lt;linux/module.h&gt;  // Basic kernel module functionality
#include &lt;linux/moduleparam.h&gt; // Module parameter support
#include &lt;linux/fs.h&gt;      // File system operations, including character device registration functions
#include &lt;linux/kdev_t.h&gt;  // Device number operation macros (e.g., MKDEV/MAJOR/MINOR)

static int major = 0;      // Static declaration of major device number (default 0 indicates dynamic allocation)
static int minor = 0;      // Static declaration of minor device number (usually 0 indicates a single device)
dev_t dev_num;             // Store the final generated device number (32 bits, high 12 bits major device number, low 20 bits minor device number)

// Declare module parameters (users can pass parameters via insmod)
module_param(major, int, S_IRUGO);  // Register readable and writable major device number parameter (S_IRUGO indicates user-readable)
module_param(minor, int, S_IRUGO);  // Register readable and writable minor device number parameter

// Module initialization function
static int __init module_param_init(void)
{
    int ret; // Used to store function return value
    
    // Check if static registration is used (major non-0)
    if (major) {
        // Combine user-specified major/minor device numbers into device number (dev_t type)
        dev_num = MKDEV(major, minor);
        
        // Print user-specified device number information (kernel log)
        printk("major:%d\n", major);
        printk("minor:%d\n", minor);
        
        // Static register device number range (register 1 device)
        ret = register_chrdev_region(dev_num, 1, "chardev_name");
        if (ret) {
            printk("register chardev region error: %d\n", ret);
            return ret; // Return error code on registration failure
        }
        printk("register chrdev is ok!\n"); 
    }
    else { // Dynamic allocation of device number (major is 0)
        // Request kernel to dynamically allocate device number (starting minor device number is minor, quantity is 1)
        ret = alloc_chrdev_region(&amp;dev_num, minor, 1, "alloc_chardev");
        if (ret) {
            printk("alloc register chrdev region error: %d\n", ret);
            return ret; // Return error on allocation failure
        }
        else {
            printk("alloc register chrdev is ok!\n");
            // Extract major/minor device numbers from allocated device number
            major = MAJOR(dev_num);
            minor = MINOR(dev_num);
            printk("alloc register major %d minor %d\n", major, minor);
        }
    }
    return 0; // Initialization successful
}

// Module exit function
static void __exit module_param_exit(void)
{
    // Release registered device number (regardless of static/dynamic registration, uniformly released)
    unregister_chrdev_region(dev_num, 1);
    printk("----chrdev end----\n");
}

// Specify module initialization and exit functions
module_init(module_param_init);
module_exit(module_param_exit);

// Module metadata
MODULE_LICENSE("GPL");              // Declare GPL license
MODULE_AUTHOR("XSX");               // Declare author
MODULE_DESCRIPTION("Module parameter example"); // Module functionality description
MODULE_VERSION("V1.0");             // Module version

Explanation

1. Device Number Management Mechanism:

• Static Allocation: Specify device number via insmod module.ko major=250 minor=0.
• Dynamic Allocation: When major=0, allocated automatically by the kernel (check via cat /proc/devices).

2. Key Operations:

• register_chrdev_region(): Pre-register known device numbers (ensure they are not occupied).
• alloc_chrdev_region(): Dynamically request device numbers (avoid conflicts).
• unregister_chrdev_region(): Uniformly release device number resources.

3. Device Number Operation Macros:

• MKDEV(major, minor): Combine major and minor device numbers → dev_t.
• MAJOR(dev): Extract major device number from dev_t.
• MINOR(dev): Extract minor device number from dev_t.

4. Log Output:

• All printk outputs to the kernel log (check via dmesg).
• Clearly distinguish between success/failure information for static/dynamic registration.

Usage Examples

1. Dynamic Allocation of Device Number:

sudo insmod module.ko
Output example:
alloc register major 246 minor 0
----chrdev end----

2. Static Allocation of Device Number:

sudo insmod module.ko major=250 minor=0
Output example:
register chrdev is ok!
----chrdev end----

3. Unload Module:

sudo rmmod module
Output example:
----chrdev end----

2. Device Model

The existence of the Linux device model is to address the critical challenges encountered by early kernels in managing and handling increasingly complex hardware and software components. Its core goal is to provide a unified, abstract, dynamic, and scalable way to describe and manage all devices and their relationships in the system.

Background

Unified Device Representation and Management

• Problem: In early kernels, different types of devices (such as PCI, USB, platform devices, virtual devices) used their own independent mechanisms for registration, discovery, and management. This led to code duplication, structural confusion, and difficulty in implementing common functionality across device types.
• Solution: The device model introduces core concepts (such as struct device, struct device_driver, struct bus_type, struct class, and struct kobject) to provide a unified abstraction layer for all hardware devices (physical or virtual) and software entities (such as DMA engines). Kernel subsystems (such as power management, hot-plugging) can work based on these common interfaces without concern for the specific type of device.

Support for Dynamic Device Discovery and Hot-Plugging

• Problem: Modern computer systems (especially servers and mobile devices) need to support hot-plugging of devices (such as USB, Thunderbolt, PCIe). The kernel needs a mechanism to dynamically perceive the addition and removal of devices and correspondingly load/unload drivers, allocate resources, and notify user space.
• Solution: The device model is the foundation for hot-plugging support. Bus drivers are responsible for detecting device insertion/removal events and sending events (uevents) to user space (such as udev) through the core mechanisms of the device model (such as kobject_uevent<code>). User space tools (udev) dynamically load drivers, create device nodes, set permissions, etc., based on event information (device type, attributes, etc.). The device tree structure maintained by the device model allows the kernel to clearly know which devices are affected.

Providing User Space Interfaces

• Problem: User space programs (such as configuration tools, monitoring tools, udev) need a standardized way to query device information, status, configuration, and receive device event notifications.
• Solution: The sysfs virtual file system is the direct embodiment of the device model in user space. It exposes kernel objects such as devices, drivers, buses, classes, and their attributes (such as device ID, power state, driver name, interrupt number, etc.) in the form of files and directories under /sys. User space programs can obtain information or perform configurations by reading and writing these files. The uevent mechanism provides event notifications.

Related Functions

Linux device management is mainly implemented through two structures: struct device and struct class. These two structures can be simply illustrated: if there are multiple ways to control LEDs in a development process, such as high/low level, PWM, I2S, etc., and each method is placed in different paths in the kernel, it is clearly not easy to manage. A unified folder named LED can be created during driver initialization to place different implementation methods, allowing the system to directly find the LED folder to manage different driver devices. The generation of this folder is implemented with the struct class structure, while the different driver implementation methods are implemented through struct device. The detailed analysis of these two structures is as follows:

struct class

• Function: Represents a class of devices with similar functions or attributes.
• Core Responsibilities: Group functionally similar devices (for example, all network interface cards belong to the net class, all block devices belong to the block class, all TTY devices belong to the tty class, all input devices belong to the input class).
• Unified User Space Interface: Creates a directory for each class under /sys/class/ (e.g., <code>/sys/class/net/). Each device belonging to this class will create a symbolic link in this directory pointing to its actual location under <code>/sys/devices/. This provides a unified view for user space to access devices categorized by function, without concern for the specific bus location or physical connection of the device.
• Class-Level Attributes: Attribute files can be defined in the class directory. These attributes will be “inherited” by all devices of that class. When user space reads or writes these attribute files, the kernel will call the callback functions provided by the class (class_attr_show and class_attr_store). Drivers can also add device-specific attribute files in the symbolic links of devices in the class directory.
• Device Management: Maintains a list of devices belonging to that class.
• Device Hot-Plug Events: When devices belonging to that class are added or removed, the class can define corresponding callback functions (such as dev_uevent) to generate standard uevent events to notify user space (such as udev) to create device nodes, set permissions, or load firmware, etc.
• Key Members (Simplified Example):

struct class {
  const char *name;                // Class name (appears under /sys/class/)
  struct module *owner;            // Module owning this class
  struct class_attribute *class_attrs; // Array of attributes for the class itself
  const struct attribute_group **dev_groups; // Default attribute groups added to each device in the class
  struct kobject *dev_kobj;        // Points to kobject under /sys/dev/ (for creating device nodes)
  int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env); // uevent callback
  char *(*devnode)(struct device *dev, umode_t *mode); // Callback for creating device node path
  void (*class_release)(struct class *class); // Class release callback
  void (*dev_release)(struct device *dev);     // Device release callback (can override device->release)
  // ... other members, such as namespace support, parent class pointer, etc ...
};

• Usage Process:

Definition: The driver developer defines an instance of struct class (usually static) and fills in the necessary members, especially name.

Registration: Call class_register(). This step creates a directory named after name under /sys/class/.

Create Device Interface (Optional but Common): Use class_create() macro or function. This is a convenience function that allocates a struct class, sets name, and calls class_register(). This is the most common way to create a class.

Associate Devices: When the driver registers a device (struct device), if the class pointer of that device is set (usually set during device initialization or driver probing), the kernel will automatically add that device to the device list of this class and create a symbolic link under /sys/class/<classname>/ pointing to <code>/sys/devices/ ...

Add Attributes: Use class_create_file() or class_attr_create() to add attribute files in the class directory. Use device_create_file() to add device-specific attribute files in the symbolic links of devices in the class directory.

Create Device Nodes (Optional): Classes usually work with udev (or mdev). When a device is registered and triggers a uevent, udev will create device nodes under /dev/ based on rules (possibly using the <code>devnode callback provided by the class). The driver can also directly call device_create() (the modern version of the internal call to class_device_create()), which will:– Create a device (struct device).– Associate the device with the specified class.– Trigger a uevent to let udev create device nodes.– Create a symbolic link for the device under /sys/class/<classname>/.

Unregister: When the module is unloaded, call class_unregister() or use class_destroy() (paired with class_create()) to unregister the class. This will delete the class directory and all its contents under /sys/class/.

struct device

• Function: Represents a specific physical or logical device.
• Core Responsibilities:

• Device Abstraction: Represents a specific device instance in the kernel. This device can be physically present (such as USB devices, PCI devices, I2C devices, platform devices) or virtual (such as DMA channels, clock sources).
• Device Hierarchy: Establishes parent-child relationships between devices through the parent pointer (for example, a USB mouse is a child device of a USB port, which is a child device of a USB controller). This reflects the physical or logical connection relationships.
• Device Driver Binding: Contains a pointer to struct device_driver (driver), indicating the driver currently controlling this device.
• Sysfs Interface: Each registered struct device will create a corresponding directory under /sys/devices/ in the kernel. This directory contains various attribute files of the device (such as <code>uevent, <code>dev, <code>subsystem, <code>driver, <code>power, etc.), allowing user space to query device status, configure, or trigger events (such as hot-plugging).
• Device Resource Management: Can associate resource information of the device (such as memory-mapped I/O addresses, interrupt numbers, DMA channels, etc.).
• Device Lifecycle Management: Provides interfaces for registration (device_register() / <code>device_add()) and unregistration (<code>device_unregister() / <code>device_del()) to manage the creation and destruction of devices.
• Power Management: Participates in system power management operations (such as suspend, resume).
• Device Namespace: Supports the concept of device namespaces.

• Key Members (Simplified Example):

struct device {
  struct device *parent;       // Pointer to parent device
  struct device_private *p;    // Internal private data (includes kobject, driver pointer, etc.)
  struct kobject kobj;         // Embedded kobject, provides sysfs representation and reference counting
  const char *init_name;       // Initial name of the device
  const struct device_type *type; // Device type
  struct bus_type *bus;        // Bus type to which the device belongs (platform, PCI, USB, I2C, SPI, etc.)
  struct device_driver *driver; // Driver bound to this device
  void *platform_data;         // Platform-specific data
  void *driver_data;           // Driver private data pointer
  struct device_node *of_node; // Associated device tree node (Open Firmware)
  // ... many other members, such as power management, DMA operations, class pointer, etc ...
};

• Usage Process:

Allocation: Typically, a struct device (or its more specific substructures, such as struct platform_device, struct pci_dev, etc.) is allocated by the bus core, platform code, or specific driver.

Initialization: Set necessary fields such as parent, bus, init_name, or of_node (for device trees).

Registration: Call device_register() or device_add(). This step is crucial:– Adds the device to the kernel’s device list.– Creates corresponding directories and attribute files under /sys/devices/.- Triggers the bus matching (<code>bus->match()) process to try to find and bind a suitable driver (<code>struct device_driver) for this device.- If the device belongs to a class (<code>class), it will also be added to the device list of that class, and a symbolic link will be created under /sys/class/<classname>/ pointing to <code>/sys/devices/....

3. Basic File Operations for Character Devices

In the Linux kernel, everything is a file, and reading and writing to character modules is equivalent to reading and writing files. The related operations for character devices in Linux can be implemented through the struct cdev structure. Below is the implementation of read and write functionality for character modules, with the overall process illustrated in the following diagram.

struct cdev

In the Linux kernel, character devices (such as serial ports, keyboards, etc.) are represented by struct cdev. Its main functions include:

• Binding Device Numbers to Device Operation Functions: struct cdev associates device numbers with a specific set of device operation functions, allowing the kernel to manage devices through these operation functions.
• Managing Character Device Registration and Unregistration: struct cdev provides functionality for registering and unregistering character devices, ensuring lifecycle management of the device in kernel space.
• Providing Device Operation Interfaces: Through the file_operations pointer, the kernel can access related file operation functions, such as open, read, write, etc.
• Core Representation of Character Devices in the Kernel: struct cdev is the core data structure for managing character devices in the kernel.
• Simplified Version of struct cdev

struct cdev {
    struct kobject kobj;          // Embedded kobject for device model and reference counting
    struct module *owner;         // Pointer to the module owning the device (usually THIS_MODULE)
    const struct file_operations *ops; // Pointer to the set of file operation functions
    struct list_head list;        // List node for adding the device to the character device list
    dev_t dev;                    // Device number (major device number + minor device number)
    unsigned int count;           // Number of associated minor device numbers
};

Each character device requires a struct cdev to represent its state and operations in the kernel. The various fields in this structure work together to ensure that character devices can be correctly registered, managed, and provide necessary functional interfaces.

Key Members Explained

• struct kobject kobj

Function: Provides representation of the device in sysfs and reference counting.Implement Device Lifecycle Management (Reference Counting): Used for device creation, deletion, and reference counting.Create Device Attributes in sysfs: Creates device attribute nodes in /sys.Support Device Hot-Plug Event Notifications: Responds to device addition and removal events.

• struct module owner

Function: Points to the module owning the device.Prevents Module from Being Unloaded While in Use: When the device file is opened, the reference count of the module is increased to prevent accidental unloading of the module.Module Reference Counting: The module can only be safely unloaded when all devices are closed.

const struct file_operations ops

• Core Function: Defines the set of operation functions supported by the device.

• Typical Operations:

struct file_operations {
  struct module *owner;
  loff_t (*llseek) (struct file *, loff_t, int);
  ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
  ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
  int (*open) (struct inode *, struct file *);
  int (*release) (struct inode *, struct file *);
  // Other operations: ioctl, mmap, poll, etc.
};

struct list_head list

Function: List node for adding the device to the global character device list.Management: The kernel manages all registered character devices through this list.

dev_t dev

Function: Stores the device number (major device number + minor device number).Operation Macros:

• MAJOR(dev_t dev): Get the major device number.
• MINOR(dev_t dev): Get the minor device number.
• MKDEV(int major, int minor): Combine major and minor device numbers.

unsigned int countFunction: Indicates the number of consecutive minor device numbers used by this device.Example: If a driver manages 3 identical devices, set count to 3.

Lifecycle Management of struct cdev

Initialization

• Static Initialization (Recommended):

void cdev_init(struct cdev *cdev, const struct file_operations *fops)
{
    memset(cdev, 0, sizeof *cdev);
    INIT_LIST_HEAD(&amp;cdev->list);
    kobject_init(&amp;cdev->kobj, &amp;ktype_cdev_default);
    cdev->ops = fops;
}

• Dynamic Allocation (Less Common):

struct cdev *cdev_alloc(void)
{
    struct cdev *p = kzalloc(sizeof(struct cdev), GFP_KERNEL);
    if (p) {
        INIT_LIST_HEAD(&amp;p->list);
        kobject_init(&amp;p->kobj, &amp;ktype_cdev_dynamic);
    }
    return p;
}

Add to System

int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
    // 1. Set device number range
    p->dev = dev;
    p->count = count;
    
    // 2. Add to global character device list
    kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
    
    // 3. Create device in sysfs
    kobject_add(&amp;p->kobj, &amp;p->owner->mkobj.kobj, "%d:%d", 
                MAJOR(dev), MINOR(dev));
    return 0;
}

Remove from System

void cdev_del(struct cdev *p)
{
    // 1. Remove from global character device list
    cdev_unmap(p->dev, p->count);
    
    // 2. Delete device from sysfs
    kobject_put(&amp;p->kobj);
}

Code

#include &lt;linux/init.h&gt;       // Module initialization and exit macros
#include &lt;linux/module.h&gt;     // Basic kernel module support
#include &lt;linux/moduleparam.h&gt; // Module parameter support
#include &lt;linux/fs.h&gt;         // File system related, including file operation structure definitions
#include &lt;linux/kdev_t.h&gt;     // Device number related macros (e.g., MKDEV)
#include &lt;linux/cdev.h&gt;       // cdev related structures and functions
#include &lt;linux/device.h&gt;     // Device class related functions (class_create, device_create)

// Device number parameters
static int major = 0;         // Major device number, 0 indicates dynamic allocation
static int minor = 0;         // Minor device number
dev_t dev_num;                // Complete device number (major + minor)

// Character device structure
struct cdev cdev_test;        // Character device instance

// Device model structure
struct class *class;          // Device class pointer
struct device *device;        // Device node pointer

// Device open function
static int cdev_test_open(struct inode *inode, struct file *file)
{
    printk("cdev file open!\r\n");
    return 0;
}

// Device read function
static ssize_t cdev_test_read(struct file *file, char __user *buf, size_t size, loff_t *off)
{
    printk("read cdev file ....\r\n");
    return 0; // Return 0 indicates reaching the end of the file (EOF)
}

// Device write function
static ssize_t cdev_test_write(struct file *file, const char __user *buf, size_t size, loff_t *off)
{
    printk("write cdev file ....\r\n");
    return size; // Return the number of bytes written, indicating success
}

// Device close/release function
static int cdev_test_release(struct inode *inode, struct file *file)
{
    printk("release cdev file ....\r\n");
    return 0;
}

// File operation structure - defines the operations supported by the device
static struct file_operations cdev_test_ops = {
    .owner = THIS_MODULE,     // Module owning this structure
    .open = cdev_test_open,   // Open device
    .read = cdev_test_read,   // Read device
    .write = cdev_test_write, // Write device
    .release = cdev_test_release // Close device
    // Note: Actual drivers need to implement more operations like ioctl, llseek, etc.
};

// Module initialization function
static int  module_param_init(void)
{
    int ret;
    
    // 1. Dynamically allocate device number (major device number allocated by the kernel)
    ret = alloc_chrdev_region(&amp;dev_num,    // Return allocated device number
                              minor,       // Requested starting minor device number
                              1,           // Number of devices
                              "alloc_chardev"); // Device name
    if (ret) {
        printk("alloc register chrdev region error: %d\n", ret);
        return ret;
    }

    printk("alloc register chrdev is ok!\n");
    major = MAJOR(dev_num);   // Extract major device number from device number
    minor = MINOR(dev_num);   // Extract minor device number from device number
    printk("alloc register major %d minor %d\n", major, minor);
    
    // 2. Initialize character device structure
    cdev_test.owner = THIS_MODULE; // Set owning module
    cdev_init(&amp;cdev_test,          // cdev structure to initialize
              &amp;cdev_test_ops);     // File operation function set
    
    // 3. Add character device to the system
    ret = cdev_add(&amp;cdev_test, // cdev to add
                   dev_num,    // Device number
                   1);         // Number of devices
    if (ret) {
        printk("cdev_add failed\n");
        goto fail_cdev_add; // Jump to error handling
    }

    // 4. Create device class (create directory under /sys/class/)
    class = class_create(THIS_MODULE, // Owning module
                         "test");     // Class name
    if (IS_ERR(class)) {
        ret = PTR_ERR(class);
        printk("class_create failed\n");
        goto fail_class_create; // Jump to error handling
    }

    // 5. Create device node (create device file under /dev/)
    device = device_create(class,    // Owning class
                           NULL,     // Parent device (none)
                           dev_num,  // Device number
                           NULL,     // Driver data (none)
                           "test");  // Device name
    if (IS_ERR(device)) {
        ret = PTR_ERR(device);
        printk("device_create failed\n");
        goto fail_device_create; // Jump to error handling
    }
    
    return 0; // Initialization successful

// Error handling (release resources in reverse order of creation)
fail_device_create:
    class_destroy(class); // Destroy device class
fail_class_create:
    cdev_del(&amp;cdev_test); // Delete character device
fail_cdev_add:
    unregister_chrdev_region(dev_num, 1); // Release device number
    return ret;
}

// Module exit function
static void  module_param_exit(void)
{
    // 1. Destroy device node (delete device file under /dev/)
    device_destroy(class, dev_num);
    
    // 2. Destroy device class (delete class directory under /sys/class/)
    class_destroy(class);
    
    // 3. Remove character device from the system
    cdev_del(&amp;cdev_test);
    
    // 4. Release device number
    unregister_chrdev_region(dev_num, 1);
    
    printk("----chrdev end----\n");
}

// Specify module's initialization and exit functions
module_init(module_param_init);
module_exit(module_param_exit);

// Module information
MODULE_LICENSE("GPL");                  // Module license
MODULE_AUTHOR("XSX");                   // Author
MODULE_DESCRIPTION("Module parameter example"); // Description
MODULE_VERSION("V1.0");                 // Version

Overall Process Diagram

Module Loading Phase

Device Operation Phase

Module Unloading Phase

Kernel Component Interaction Relationships

Kernel Data Interaction

Data operations between the user layer and kernel layer in Linux are mainly performed through the functions copy_from_user() and copy_to_user().

copy_from_user(): Copies data from user space to kernel space (user -> kernel).

copy_to_user(): Copies data from kernel space to user space (kernel -> user).

These two interfaces are used to transfer buffer data between the kernel and user processes and must be used with caution to avoid memory leaks, kernel crashes, or permission issues.

Prototype

#include &lt;linux/uaccess.h&gt;

unsigned long copy_from_user(void *to, const void __user *from, unsigned long n);
unsigned long copy_to_user(void __user *to, const void *from, unsigned long n);

Returns the number of bytes not copied. 0 indicates success, non-zero is usually considered an error (the kernel often returns -EFAULT).

Example

char *kbuf = kmalloc(len, GFP_KERNEL);
if (!kbuf) return -ENOMEM;
if (copy_from_user(kbuf, ubuf, len)) { kfree(kbuf); return -EFAULT; }
/* ... */
if (copy_to_user(ubuf, kbuf, len)) { kfree(kbuf); return -EFAULT; }
kfree(kbuf);

Code

Driver File

#include &lt;linux/init.h&gt;        /* module init/exit macros */
#include &lt;linux/module.h&gt;      /* module related (MODULE_*) */
#include &lt;linux/moduleparam.h&gt; /* module parameters (if needed) */
#include &lt;linux/fs.h&gt;          /* file_operations, struct file, etc. */
#include &lt;linux/kdev_t.h&gt;      /* MKDEV, MAJOR, MINOR */
#include &lt;linux/cdev.h&gt;        /* cdev related */
#include &lt;linux/device.h&gt;      /* class_create / device_create */
#include &lt;linux/uaccess.h&gt;     /* copy_to_user / copy_from_user */
#include &lt;linux/string.h&gt;      /* strlen, if using string functions in kernel */

/* Global variables: major and minor device numbers and device structure */
static int major = 0;
static int minor = 0;
dev_t dev_num;               /* Used to save allocated device number */
struct cdev cdev_test;       /* Character device structure */
struct class *class;         /* Device class (for udev/sysfs) */
struct device *device;       /* Device object (for creating /dev/test) */

/* open callback */
static int cdev_test_open(struct inode *inode, struct file *file)
{
    printk("cdev file open!\r\n"); /* Simple log */
    return 0;                      /* Return 0 indicates success */
}

/* read callback */
static ssize_t cdev_test_read(struct file *file, char __user *buf, size_t size, loff_t *off)
{
    printk("read cdev file ....\r\n");
    return 0; // Return 0 indicates reaching the end of the file (EOF)
}

/* write callback */
static ssize_t cdev_test_write(struct file *file, const char __user *buf, size_t size, loff_t *off)
{
    printk("write cdev file ....\r\n");
    return size; // Return the number of bytes written, indicating success
}

/* release (close) callback */
static int cdev_test_release(struct inode *inode, struct file *file)
{
    printk("release cdev file ....\r\n");
    return 0;
}

/* file_operations structure, exported to kernel file system calls */
static struct file_operations cdev_test_ops = {
    .owner = THIS_MODULE,
    .open = cdev_test_open,
    .read = cdev_test_read,
    .write = cdev_test_write,
    .release = cdev_test_release
    // Note: Actual drivers need to implement more operations like ioctl, llseek, etc.
};

/* module initialization: register character device and create device node */
static int module_param_init(void)
{
    int ret;
    
    /* Allocate major/minor device number (dynamic allocation) */
    ret = alloc_chrdev_region(&amp;dev_num, minor, 1, "alloc_chardev");
    if (ret) {
        printk("alloc register chrdev region error: %d\n", ret);
        return ret;
    }

    printk("alloc register chrdev is ok!\n");
    major = MAJOR(dev_num);
    minor = MINOR(dev_num);
    printk("alloc register major %d minor %d\n", major, minor);

    /* Initialize cdev and add to system */
    cdev_test.owner = THIS_MODULE;
    cdev_init(&amp;cdev_test, &amp;cdev_test_ops);
    ret = cdev_add(&amp;cdev_test, dev_num, 1);
    if (ret) {
        printk("cdev_add failed: %d\n", ret);
        unregister_chrdev_region(dev_num, 1);
        return ret;
    }

    /* Create device class and device node /dev/test (for udev to create device file) */
    class = class_create(THIS_MODULE, "test");
    if (IS_ERR(class)) {
        pr_err("class_create failed\n");
        cdev_del(&amp;cdev_test);
        unregister_chrdev_region(dev_num, 1);
        return PTR_ERR(class);
    }

    device = device_create(class, NULL, dev_num, NULL, "test");
    if (IS_ERR(device)) {
        pr_err("device_create failed\n");
        class_destroy(class);
        cdev_del(&amp;cdev_test);
        unregister_chrdev_region(dev_num, 1);
        return PTR_ERR(device);
    }
    
    return 0;
}

/* module exit: destroy device and unregister device number */
static void module_param_exit(void)
{
    device_destroy(class, dev_num);
    class_destroy(class);

    cdev_del(&amp;cdev_test);
    unregister_chrdev_region(dev_num, 1);

    printk("----chrdev end----\n");
}

module_init(module_param_init);
module_exit(module_param_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("XSX");
MODULE_DESCRIPTION("Module parameter example");
MODULE_VERSION("V1.0");

Application Code

#include &lt;stdio.h&gt;
#include &lt;sys/types.h&gt;
#include &lt;sys/stat.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;unistd.h&gt;
#include &lt;string.h&gt;
#include &lt;errno.h&gt;

/* Simple device test program:
 * - Open /dev/test (read/write)
 * - Read fixed size data and print
 * - Write data to the device
 */

int main(int argc, char *argv[])
{
    /* Open device file, O_RDWR means read/write */
    int fd = open("/dev/test", O_RDWR);
    if (fd < 0) {
        /* Use perror to print standard error message for easier problem localization */
        perror("open /dev/test");
        return fd;
    }

    /* Read buffer: here using fixed size read example */
    char read_buf[32] = {0};           /* Initialize to 0, ensure NUL termination */
    ssize_t r = read(fd, read_buf, sizeof(read_buf) - 1); /* Leave 1 byte for NUL */
    if (r < 0) {
        perror("read");
        close(fd);
        return 1;
    }
    /* r is the actual number of bytes read, ensure string is NUL terminated */
    read_buf[r] = '\0';
    printf("read data: %s (bytes=%zd)\n", read_buf, r);

    /* Write buffer: only write actual string length, not the entire array */
    char write_buf[32] = "helloworld!";
    siz

Linux Kernel Character Module (Part II)

1. Registering Device Numbers

1.1 Device Number Structure

1.2 Device Number Registration Methods

Static Registration

Dynamic Registration

2. Kernel Implementation Mechanism

3. Device Number Lifecycle Management

4. Usage Methods

Code

Explanation

Usage Examples

Background

Related Functions

struct class

struct device

3. Basic File Operations for Character Devices

struct cdev

Lifecycle Management of struct cdev

Code

Overall Process Diagram

Module Loading Phase

Device Operation Phase

Module Unloading Phase

Kernel Component Interaction Relationships

Kernel Data Interaction

Prototype

Example

Code

Application Code

Leave a Comment Cancel reply