Linux kernel device driver advanced character device driver notes

/******************
 * Advanced character device driver *********************/

(1)ioctl

In addition to reading and writing to devices, most drivers require the ability to perform various types of hardware control through device drivers. For example, eject media, change baud rate, etc. These operations are supported via the ioctl method, which implements the system call of the same name.

In user space, the prototype of the ioctl system call is:

int ioctl(int fd, unsigned long cmd, ...);
fd: open device file descriptor
cmd: command
The third parameter: Depending on the command, it can be an integer, a pointer, or none.
The "..." method is used only to avoid compiler errors.

The prototypes of the driver's ioctl methods are slightly different from the userspace versions:

int (*ioctl) (struct inode *inode,
struct file *filp,
unsigned int cmd,
unsigned long arg);
inode/filp: corresponding to the fd of user space
cmd: corresponds to the cmd sent from user space
arg: corresponding to the cmd parameter passed

Most ioctl implementations include a switch statement to select the corresponding operation based on the cmd parameter. The command numbers in user space and kernel space must be consistent.

(2) Select the ioctl command number

Before writing ioctl code, you need to choose numbers corresponding to different commands. You can't simply choose the number starting from 0 or 1, because Linux requires that this command number should be unique system-wide. The Linux kernel uses a convention to select ioctl numbers for drivers. You can refer to include/asm/ioctl.h and Documentation/ioctl-number.txt.

An ioctl number is 32 bits long. Linux divides it into four parts. The macros needed to construct an ioctl number are defined in <linux/ioctl.h>:

type 8-bit magic number. In fact, it is to select a number for your driver. Refer to ioctl-number.txt
number 8-digit ordinal number.
direction 2 bits. Defines the direction of data transmission. Such as _IOC_NONE (no data transmission), _IOC_READ|_IOC_WRITE (bidirectional data transmission). Note that this direction is for the user, so IOC_READ means reading data from the device and the driver should write data to user space.
size 14 bits. The size of the user data involved.

You can use the macros in <linux/ioctl.h> to construct an ioctl number

_IO(type, nr)
_IOR(type,nr,datatype)
_IOW(type,nr,datatype)

Return Value

For system calls, positive return values are protected first, while negative values are considered an error and are used to set the error variable in user space. If an undefined ioctl number is passed in when calling the ioctl method, the error value returned by the system is -ENVAL and -ENOTTY.

(3) Blocking and non-blocking operations

For operations such as read and write, the default operation is blocking, and its characteristics are:

*If a process calls read but there is no data to read, the process must block. When data arrives, the process is awakened and the data is returned to the caller, even if the amount of data is less than the data specified by the count parameter.

*If a process calls write but there is no space in the buffer, this process must block and must sleep on a wait queue different from the reading process. When some data is written to the hardware device, thus freeing up part of the output buffer, the process is awakened and the write call succeeds.

Sometimes we want to change this feature and make it non-blocking, so that the read/write method returns immediately regardless of whether the device has data to read or write.

If you want to set a file to be non-blocking, you should set the O_NONBLOCK flag of filp->f_flags. When dealing with non-blocking files, applications must be very careful when calling stdio functions, because it is easy to mistake a non-blocking return for EOF, so errno must always be checked.

(4) Asynchronous Notification

a. The role of asynchronous notification

Most of the time a combination of blocking and non-blocking operations and the select method can effectively query the device, but there are times when this technique is not efficient. In the face of certain random or rarely occurring situations (such as typing CTRL+C on the keyboard), asynchronous notification is required.

b. How to start asynchronous notification in user space program

To start the asynchronous notification mechanism for a file, the user program must perform two steps:

01.Specify a process as the "owner" of the device file. When a process executes the F_SETOWN command using the fcntl system call, the process ID of the owner process is saved in filp->f_owner. This step is necessary so that the kernel knows who to notify.
02. In order to actually start the asynchronous notification mechanism, the user program must also set the FASYNC flag in the device, which is done through the fchtl command F_SETFL. After performing these two steps, the device file can request a SIGIO signal when new data arrives. The signal is sent to the process stored in file->f_owner (or the process group if it is negative). Not all devices support asynchronous notifications, and applications usually assume that only sockets and terminals have asynchronous notification capabilities.

(5) How to implement asynchronous notification in the driver

a. Correspondence of user space operations in the kernel

01. When setting F_SETOWN, assign a value to file->f_owner
02. When F_SETFL is executed to start FASYNC, the driver's fasync method is called. This method is called whenever the FASYNC flag in filp->f_flags (cleared by default when the file is opened) is changed.
03. When data arrives, the kernel sends a SIGIO signal to all processes registered for asynchronous notification

b. Add the fasync_struct pointer to the device structure

This structure is defined in <linux/fs.h>:

struct fasync_struct {
int magic;
int fa_fd;
struct fasync_struct *fa_next;
struct file *fa_file;
};

c. Two functions to be called by the driver

These two functions are declared in <linux/fs.h>.

Defined in /fs/fcntl.c.

The prototype is as follows:

01. int fasync_helper(int fd, struct file *filp, int mode, struct fasync_struct **fa);
02. void kill_fasync(struct fasync_struct **fa, int sig, int band);

When the FASYNC flag of an open file is modified, fasync_helper is called to add or remove the file from the list of associated processes, and kill_fasync notifies all associated processes when data arrives.

d. Example

01. Define the fasync_struct dynamic data structure in the device type

struct my_pipe {
  struct fasync_struct *async_queue; /* Asynchronous read structure*/
......
};

02. The fasync function in the driver calls fasync_helper

int my_fasync(fasync_file fd, struct file *filp, int mode)
{
  my_pipe *dev = filp->private_data;
  return fasync_helper(fd, filp, mode, &dev->async_queue);
}

03. Call kill_fasync when the asynchronous notification conditions are met

The asynchronous notification is for a reading process, so kill_fasync should be sent using write.

Call kill_fasync to send the signal SIGIO to all processes registered in the asynchronous queue async_queue on the device.

ssize_t my_write(struct file *filp, const char *buf, size_t count,
        loff_t *f_pos)
{
......
if (dev->async_queue)
    kill_fasync(&dev->async_queue, SIGIO, POLL_IN); 
    ......
}

04. The fasync method must be called when closing a file

The fasync method must be called when closing a file in order to remove the file from the list of active asynchronous readers.

Call in release: scull_p_fasync(-1, filp, 0);

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

You may also be interested in: