File, inode in the application layer and drive layer of the link between __ embedded

Application layer and drive interface, has been a long-standing problem, if not clear, always feel that the driver write plausible. Here's what I understand about them, and how to implement a driver to support multiple devices on the issue. The main two mechanisms involved: Inode and file

In drive:

(1), we first find a device number DEVNO, can be dynamically applied, can also be set statically, assuming static settings for Major,minor, through the macro Mkdev (Major,minor) to generate Devno

(2) Construction of the operation function of the equipment file_opreation structure, which contains the operation of the equipment: open, read, write, release, IOCTL, etc.

(3), constructs the CDEV structure body, inside fills two main member dev (equipment number), file_operation (to the equipment operation)

(4), add Cdev to the Cdev list: Cdev_init, Cdev_add

In your application:

Fd=open ("/dev/hello", O_RDWR) to open the device file, this device node should have a device number, this is our identification of the driver and equipment bridge.

Open/dev/hello, according to the device number, in the Cdev linked list to find CDEV This structure, Cdev contains the file_operation structure, a variety of equipment operations, open on the call inside. Open function. Here are a few things to accomplish:

(1) Inode node each file should have an Inode node, the inode structure. I_fop is populated by Cdev file_operation, I_dev by Cdev's device number

(2) The file_operation in the file structure is also populated by the corresponding item in the Cdev, and there is an FD corresponding to the file descriptor for the open file, fd and file one by one, and each time the file is opened, there is a filename structure it. So the. Private in file is very important, the following will be said.

There is also a problem, that is, many of the same device, will be common to the same driver, so to each device's private data packaging, constitute a private structure of data structures. Every reading and writing of the equipment is done by manipulating the resources in the private data structure of the device. In other words, the driver in the load, will request a number of devices private resource structure, each structure contains all the private resources of the device, although a common driver, but through the device number to find this device number corresponding to the device's private resources, said a bit clumsy. This can be pointed to by the. Private of the file structure.

For example, the structure that encapsulates private data is:

struct hello_device{

Char buf[128]; Private resources for devices, such as buf

struct Cdev cdev;//equipment structure with DEVNO and file_operation

......

};

It should be mentioned earlier that the I_cdev in the inode will point to the CDEV structure, so the address of hello_device can be obtained by the container macro.

So, there are two parameters in the driven open function, and the inode and file

int open (STRUCTC inode *inode,struct file *file) {

struct Hello_device *p =container (Inode->i_cdev,hello_struct,cdev)

file->private=p;

}

In this case, the file contains private data for the device.

Drive the Read function:

ssize_t Read (Fd,char __user *buf,count)

FD and file one by one correspond, each time the device is opened, although there are different fd, but their file.private is the same.

The front is mainly about how a driver can support multiple devices, and the connection between the application layer and the driver. Another problem is how to handle the problem of having a process access the same device.