Linux kernel device driver character device driver notes

/********************
 * Character device driver************************/

(1) Introduction to character device drivers

Character devices refer to devices that are accessed by byte streams, and the drivers for character devices are called character device drivers.

This type of driver is suitable for most simple hardware devices. For example, for a parallel printer, we access it by creating a device file (such as /dev/printer) under /dev.

The user application opens the dev/printer with the standard open function, then uses write to write data to the file and read data from it with read.

Calling process:

• write(): user space -->
• sys_write(): VFS -->
• f_op->write: write method for a specific device

The so-called driver provides the final write function and communicates directly with the printer by accessing the registers of the printer hardware.

(2) Major device number and minor device number

a. Equipment number introduction

Access to character devices is through device files within the file system. These files are located in /dev. Use "ls -l" to view.

Devices are identified by device numbers. The device number consists of two parts, the major device number and the minor device number.

Usually, the major device number identifies the driver corresponding to the device. Linux allows multiple drivers to share the same major device number.

The minor device number is used to determine the device to which the device file refers.

In the kernel, the dev_t type <linux/types.h> is used to store device numbers.

The 2.4 kernel uses 16-bit device numbers (8 bits for master and 8 bits for slave), while the 2.6 kernel uses 32 bits, 12 bits for master and 20 bits for slave.

To access the device number in the driver, you should use the macros defined in <linux/kdev_t.h>.

Get the device number:

• MAJOR(dev_t dev)
• MINOR(dev_t dev)
• MKDEV(int major, int minor)

b. Allocate and release device numbers

Before creating a character device, the driver needs to obtain the device number.

distribute:

#include <linux/fs.h>
int register_chrdev_region(dev_t first, unsigned int count, char *name);
//first: the starting value of the device number range to be allocated (the secondary device number is usually set to 0)
//count: requested consecutive number range //name: device name associated with the number (see /proc/devices)

You can also ask the kernel to allocate dynamically:

int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name);
//firstminor: usually 0
//*dev: stores the device number returned by the kernel

release:

void unregister_chrdev_region(dev_t first, unsigned int count);
//Called in the module's clear function

The device numbers that the kernel has assigned can be found in Documentation/devices.txt.

c. Create device files

Once the device driver module has applied for the major and minor device numbers from the system and has been loaded into the kernel through insmod, we can access the device by creating a device file under /dev.

Creation of character device: $>mknod /dev/mychar c major minor

We often use the method of dynamically allocating major and minor device numbers in the driver, so that there will be no conflict with the existing device numbers in the system.

When dynamically allocated, the device files under /dev also need to be dynamically created by analyzing /proc/devices.

See the char_load and char_unload scripts.

(3) Basic data structure of character devices

The three basic data structures that are most closely related to character device drivers are: file, file_oepeations, and inode

a.file_operations data structure

The structure contains several function pointers. These functions are the ones that actually interact with the hardware.

Functions such as open and write called by user space will eventually call the function pointed to by the pointer here. Each open file is associated with a set of functions.

See <linux/fs.h> and p54 of the driver book

2.6 Initialization of kernel structure:

struct file_operations my_fops = {
.owner = THIS_MODULE,
.llseek = my_llseek,
.read = my_read,
.write = my_write,
.ioctl = my_ioctl,
.open = my_open,
.release = my_release,
}

2.4 Initialization of kernel structure:

struct file_operations my_fops = {
owner: THIS_MODULE,
llseek: my_llseek,
...
}

b.file structure <linux/fs.h>

File is a kernel structure, which actually corresponds to the file descriptor fd returned by the user after opening the file.

The file structure represents an open file. Each open file in the system has a corresponding file structure in the kernel space.

It is created by the kernel at open time and passed to all functions that operate on the file until the final close function, at which point the kernel releases the structure after all instances of the file have been closed.

After the user space process forks a new process, the new and old processes will share the open file descriptor fd. This operation will not create a new file structure in the kernel space, but will only increase the count of the created file structure.

See <linux/fs.h>

mode_t f_mode; FMODE_READ and FMODE_WRITE are used to indicate whether the file is readable or writable.

loff_t f_pos; Current read and write position, loff_t is 64 bits

unsigned int f_flags; File flags, such as O_RDONLY, O_NONBLOCK, O_SYNC. The flags are defined in <linux/fcntl.h>

struct file_operations *f_op; File-related operations. The kernel assigns a value to this pointer when executing open. You can assign different f_ops to the driver's open method according to the minor device number.

void *private; The structure representing the hardware device is usually assigned to private.

struct dentry *f_dentry; The directory entry (dentry) structure corresponding to the file. The inode can be accessed via filp->f_dentry->d_inode.

The rest of the file has little to do with the driver.

c.inode structure

The kernel uses the inode structure to represent an actual file, which can be a normal file or a device file.

Each file has only one inode structure, but there can be multiple file structures corresponding to the file descriptor (multiple open calls). These files all point to the same inode.

inode is defined in <linux/fs.h>

dev_t i_rdev; For the inode structure representing the device file, i_rdev contains the actual device number

struct cdev *i_cdev cdev is a kernel internal structure that represents a character device. When the inode represents a character device, i_cdev points to the struct cdev in the kernel.

Other structures have little to do with device drivers.

Use the following macro to get the device number from the inode:

• unsigned int iminor(struct inode *inode)
• unsigned int imajor(struct inode *inode)

(4) Registration of character devices

The kernel uses the struct cdev structure to represent a character device.

Our driver needs to register its own cdev into the kernel. See <linux/cdev.h>

a. Usually add cdev to the device structure

struct scull_dev{
...
struct cdev cdev; /* character device structure*/
}

b. Initialization

void cdev_init(struct cdev *cdev, struct file_operations *fops)

c. Set the content in cdev

• dev->cdev.owner = THIS_MODULE;
• dev->cdev.ops = &scull_fops;

d. Add the set cdev to the kernel

int cdev_add(struct cdev *dev, dev_t num, unsigned int count);
//num: the first number corresponding to the device //count: the number of device numbers associated with the device, usually 1
//Once cdev_add returns, the kernel considers the device to be usable, so the hardware initialization of the device must be completed before calling it.

(5) Old-style registration function

The old registration functions from 2.4 are still present in many driver functions, but new code should not use them.

register:

int register_chrdev(unsigned int major,
  const char *name,
  struct file_operations *fops);
//Register 0~255 as the minor device number for the given major device number, and create a corresponding default cdev structure for each device

Logout:

int unregister_chrdev(unsigned int major,
  const char *name);

(6) open and release

a.open

The device initialization is completed in the driver's open method. After the open is completed, the hardware can be used and the user program can access the device through write and other methods. The open work includes:

• * Check for device specific errors
• * If the device is opened for the first time, initialize it (it is possible to call open multiple times)
• * If necessary, update the f_op pointer
• * Allocate and fill in the data placed in filp->private_data

open prototype;

int (*open) (struct inode *inode, struct file *filp);
//Get the dev pointer through inode in open and assign it to file->private_data
//struct scull_dev *dev;
//dev = contain_of(inode->i_cdev, struct scull_dev, cdev);
//filp->private_data = dev;
//(If dev is statically allocated, you can directly access dev in methods such as open or write, but if dev is dynamically allocated during module_init, you can only get its pointer through the above method)

b.release

Not every close call will cause a call to the release method. Only when the file counter reaches zero will release be called to release the dev structure.)

(7) read and write

The job of read and write is to copy data from user space to the kernel, or to copy kernel data to user space. Its prototype is:

ssize_t read(struct file *filp, char __user *buff, size_t count, loff_t *offp);
ssize_t write(struct file *filp, const char __user *buff, size_t count, loff_t *offp);
//buff: pointer to the user space buffer //offp: the location where the user performs access operations in the file //In read and write, after copying the data, offp should be updated and the actual number of bytes copied should be returned.

(8) Exchange data with user space

__user *buff in read and write is a pointer to user space. The kernel cannot directly reference its contents (that is, it cannot directly access the value of buff). Data copying is required through the functions provided by the kernel. The reasons are:

• a. Depending on the architecture, user space pointers may be invalid when running in kernel mode.
• b. User space memory is paged. When a system call is executed, the memory pointed to by buff may not be in RAM at all (it has been swapped to disk)
• c. This may be an invalid or malicious pointer (for example, pointing to kernel space)

The functions for exchanging data between kernel and user space are shown in <asm/uaccess.h>

like:

1. unsigned long copy_to_user(
void __user *to,
const void *from,
unsigned long count);
//Copy data to user space

2. unsigned long copy_from_user(
void *to,
const void __user *from,
unsigned long count);
//Get data from user space

3. int put_user(datum, ptr)
//Copy data to user space. The number of bytes is determined by sizeof(*ptr)
//The return value is 0 for success and negative for error.

4. int get_user(local, ptr);
//Get data from user space. The number of bytes is determined by sizeof(*ptr)
//The return value and local are data obtained from user space

Any function that accesses user space must be sleepable, and these functions need to be reentrant.

If the return value of functions such as copy_to_user is not equal to 0, read or write should return -EFAULT to user space.

The major device number is used to indicate the device driver, and the minor device number indicates the device using this driver.

In the kernel, dev_t represents the device number, which consists of the major device number and the minor device number.

#include <linux/kdev_t.h>
#define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS)) //Get the major device number based on the device number#define MINOR(dev) ((unsigned int) ((dev) & MINORMASK)) //Get the minor device number#define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) //Generate the device number based on the specified major and minor device numbers#include <linux/fs.h> 
//Static: Apply for the specified device number, from refers to the device number, count refers to how many devices (minor device numbers) use this driver, device name int register_chrdev_region(dev_t from, unsigned count, const char *name);
//The length of name cannot exceed 64 bytes //Dynamically apply for device numbers. The kernel allocates unused major device numbers. The allocated devices are stored in dev. baseminor refers to the starting number of the minor device number. count refers to the number of devices. name device name int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count,
const char *name)
//Release the device number, from refers to the device number, count refers to the number of devices void unregister_chrdev_region(dev_t from, unsigned count)
//cat /proc/devices can view the device usage. In the documentations/devices.txt of the kernel source code, you can view the static allocation of device numbers. ///The kernel uses struct cdev to describe a character device driver. #include <linux/cdev.h>
struct cdev {
struct kobject kobj; //The kernel manages character device drivers struct module *owner; //Usually set to THIS_MODULE to prevent the driver module from being unloaded while in use const struct file_operations *ops; //How to operate (vfs)
struct list_head list; //Since multiple devices can use the same driver, use a linked list to record dev_t dev; //Device number unsigned int count; //Number of devices};

////////Character device driver//////////

1. Apply for a device number

2. Define a cdev device driver object

struct cdev mycdev; 
//Define a file operation object of file_operations struct file_operations fops = {
.owner = THIS_MODULE,
.read = read function....
};

3. Associate the fops object with mycdev

cdev_init(&mycdev, &fops); //mycdev.ops = &fops;
mycdev.owner = THIS_MODULE;

4. Add the device driver to the kernel and specify the device number corresponding to the driver

cdev_add(&mycdev, device number, number of secondary device numbers);

5. When uninstalling the module, remove the device driver from the kernel and unregister the device number.

cdev_del(&mycdev);
///////////Create device file mknod /dev/device file name c major device number minor device number /////////inode node object describes a file/device file, including permissions, device number and other information struct inode {
...
dev_t i_rdev; //Device number corresponding to the device file struct cdev *i_cdev; //Points to the address of the corresponding device driver object...
};
////The file object describes the file descriptor, which is created when the file is opened and destroyed when it is closed. struct file {
...
const struct file_operations *f_op; //The address of the corresponding file operation object unsigned int f_flags; //File open flag fmode_t f_mode; //Permission loff_t f_pos; //File descriptor offset struct fown_struct f_owner; //Which process does it belong to unsigned int f_uid, f_gid; 
void *private_data; //For driver programmers to use...
};

The device number of the device file can be obtained through the member f_path.dentry->d_inode->i_rdev in file

///Error code in <asm/errno.h> ////

/////////struct file_operations ////

inode represents the node object of the file opened by the application, and file represents the file descriptor obtained by opening the file.

Returns 0 if successful, returns an error code if failed

int (*open) (struct inode *, struct file *);

buf points to the buffer in the user process, and len indicates the size of buf (passed in by the user when calling read)

off represents the operation offset of the fl file descriptor, and the return value is the number of bytes of data actually given to the user.

ssize_t (*read) (struct file *fl, char __user *buf, size_t len, loff_t *off);

The user process gives data to the driver

ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);

to refers to the buffer of the user process, from refers to the buffer of the driver that holds the data, n is the number of bytes, and the return value is 0

extern inline long copy_to_user(void __user *to, const void *from, long n)

to refers to the driver... from the user... n is how many bytes, ....

static inline unsigned long __must_check copy_to_user(void __user *to, const
void *from, unsigned long n)
{
if (access_ok(VERIFY_WRITE, to, n))
n = __copy_to_user(to, from, n);
return n; //The return value is the number of bytes left to copy}

extern inline long copy_from_user(void *to, const void __user *from, long n)

• If the data to be interacted with by the user process is 1, 2, 4, or 8 bytes, put_user(x, p) can be used //x is the value, p is the address
• If you want to get 1, 2, 4 bytes from the user process, you can use get_user(x,p)

///////////
///Dynamically apply for memory and clear it. Size is the size of the application (not more than 128K),
//flags is the flag (usually GFP_KERNEL). Returns the address if successful, NULL if failed
// GFP_ATOMIC, use the system's memory emergency pool void *kmalloc(size_t size, gfp_t flags); //The memory needs to be cleared after application void *kzalloc(size_t size, gfp_t flags); //The memory applied for has been cleared void kfree(const void *objp); //Reclaim kmalloc/kzalloc's memory void *vmalloc(unsigned long size); //Apply for large memory space void vfree(const void *addr); //Reclaim vmalloc's memory // The memory applied for by kmalloc has continuous physical addresses, while vmalloc is not necessarily continuous ///// container_of(ptr, type, member) type is a structure including member members,
//ptr is the address of the member of the type structure.
//This macro gets the first address of the structure variable according to the address of the structure member#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr - offsetof(type,member) );})
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
 15 typedef struct led_dev_t {
 16 dev_t mydevid;
 17 unsigned int *rLEDCON;
 18 unsigned int *rLEDDAT;
 19 struct cdev mycdev;
 20 }LED_DEV;
 LED_DEV myled;
 //ind->i_cdev is the address pointing to the member of myled.mycdev //The first address of the structure variable myled can be obtained by container_of(ind->i_cdev, LED_DEV, mycdev);

/////// Automatically create device files////

#include <linux/device.h>

1.

struct class *cl; 
cl = class_create(owner, name); //owner refers to which module it belongs to, name class name//After creation, you can view /sys/class/class name void class_destroy(struct class *cls); //Used to destroy the created class

2. Create device files

struct device *device_create(struct class *cls, struct device *parent,
  dev_t devt, void *drvdata,
  const char *fmt, ...)
  __attribute__((format(printf, 5, 6)));
device_create(class, NULL, device number, NULL, "mydev%d", 88); //Create a device file named mydev88 in the /dev/ directory void device_destroy(struct class *cls, dev_t devt); //Used to destroy the created device file////////
int register_chrdev(unsigned int major, const char *name,
  const struct file_operations *fops) ; //Register the device number and create a driver object void unregister_chrdev(unsigned int major, const char *name); //Unregister the device number and delete the driver object static inline int register_chrdev(unsigned int major, const char *name,
 const struct file_operations *fops)
{
return __register_chrdev(major, 0, 256, name, fops);
}
int __register_chrdev(unsigned int major, unsigned int baseminor,
   unsigned int count, const char *name,
   const struct file_operations *fops)
{
struct char_device_struct *cd;
struct cdev *cdev;
int err = -ENOMEM;
cd = __register_chrdev_region(major, baseminor, count, name);
if (IS_ERR(cd))
return PTR_ERR(cd);
cdev = cdev_alloc();
if (!cdev)
goto out2;
cdev->owner = fops->owner;
cdev->ops = fops;
kobject_set_name(&cdev->kobj, "%s", name);
err = cdev_add(cdev, MKDEV(cd->major, baseminor), count);
if (err)
goto out;
cd->cdev = cdev;
return major ? 0 : cd->major;
out:
kobject_put(&cdev->kobj);
out2:
kfree(__unregister_chrdev_region(cd->major, baseminor, count));
return err;
}

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links