Analysis on the advantages and disadvantages of UIO user driver driven by Linux device

"Abstract" Linux User Configuration device-driven development: Not all device drivers are written in the kernel, and in some cases, writing drivers in user space can better address the problems encountered. This paper analyzes the advantages and disadvantages of user-driven drivers.

1. Advantages of User space driver

1, can be linked with the entire C library.

2, in the drive can use floating point number, in some special hardware, may need to use floating point number, and the Linux kernel does not provide floating point support. This problem can be easily solved if the driver is implemented in the user state.
3. Drive problems will not cause the entire system to hang. Some errors that are driven by the kernel state often cause the entire system to hang.

4, the user state of the driver debugging convenience.

5, can give the driver of the closed source code, do not need to use the GPL, more flexible

2. Disadvantage of user space driver

1. Interrupts cannot be used. Interrupts are not available in user space, and the latest UiO interface has addressed this issue.

Some hardware vendors only provide user-space drivers that match some Linux development versions (often obsolete). Although the user space driver is controversial, the kernel chooses to support it. The newest interface is called UiO (the previous kernel also has, but the new version makes a lot of changes), it was in a patch in version 2.6.22, and was formally incorporated into the kernel's code tree in 2.6.23. There have been some changes to this interface than before. As in previous versions, UiO did not completely cancel the kernel space code. There is a small module in the kernel that is used to establish a device or interface (interface) connected to the PCI bus and to provide interrupt handlers. This (interrupt handler) is important, although there are more things that can be done in user space, but there is still a need for an interrupt handler in the kernel to notify the device to stop sending interrupts.

The kernel module needs to include < linux/uio_driver.h>. If he is a driver of a PCI device, the PCI driver needs to be registered as required by the unified device model. When the device needs to be connected (possibly in the PCI probe () function), the driver needs to fill in a uio_info structure:

structUio_info {Char*name;Char*version;structUio_mem Mem[max_uio_maps];LongIrq UnsignedLongIrq_flags;void*priv; Irqreturn_t (*handler) (intIrqstructUio_info *dev_info);int(*mmap) (structUio_info *info,structVm_area_struct *VMA);int(*open) (structUio_info *info,structInode *inode);int(*release) (structUio_info *info,structInode *inode);/ * Internal Stuff omitted * /};

In the structure above, name is the name of the device, version is the driver's build number (which will be displayed in Sysfs), the IRP is the IRQ number used by the device, and Irq_flags is the interrupt call flag, which is passed to REQUEST_IRQ (); handler () Is the interrupt handler, in addition to answering the hardware interrupt, generally do not do any other work; Mmap ()/open ()/release () is called by the corresponding member in the File_operations

The mem array in the struct is used to describe any area of memory that can be mapped to user space. The main members of the UIO_MEM structure are as follows:

struct uio_mem {  unsigned long addr;  unsigned long size;  int memtype;  void __iomem *internal_addr;  ... */};

For each zone that can be mapped, addr is the address (physical address) of the zone, the size of the area, and INTERNAL_ADDR is the address (virtual address) of the zone returned by Ioremap ().
The Memtype is used to describe the properties of the zone, including:
*uio_mem_phys
Indicates that addr is a physical address, typically used in the I/O memory area
*uio_mem_logical
The zone is in the logical address space of the kernel, such as those obtained through Kmalloc ()
*uio_mem_virtual
The zone is in the virtual address space of the kernel, which is used by Vmalloc_user ()
Once the uio_info structure is completed, the driver passes it to the following function:
int Uio_register_device (struct device *parent, struct uio_info *info);
The parent pointer tells the kernel that the UiO device is associated with which "real" device, and if the driver is for a PCI device, the parent points to Pci_dev->dev.
Kernel space UiO Basically on these APIs, when the device is removed, the driver needs to be called:
void Uio_unregister_device (struct uio_info *info);
The last function associated with the notification (note) is:
void uio_event_notify (struct uio_info *info);
The purpose of this function is to notify the UiO core that an event has occurred (typically an interrupt). When a real interrupt occurs, the stub driver does not have to call Uio_event_notify (), but this function can simulate interrupts in other cases.

In user space, the first UiO processing device will be displayed as/dev/uio0 (assuming Udev has started). The driver for the user space will open the device. The read operation on the device returns an int value that holds the event count (how many interrupts occurred). If no interrupts have been generated since the last time the device was read, the read operation will block until an interrupt occurs (of course, non-blocking operations are supported). The file descriptor can be sent to poll ().

The memory regions described in kernel space drivers can be mapped to user space through Mmap () calls. The arguments passed to mmap () have some strange, nth regions of the kernel, and the value of the offset parameter will be nth times the current page size. That is, if the page size of the current system is 4,096 bytes, the offset value of the first memory area of the map is 0, and the second memory area is 4096, the third is 8192, and so on.

Of course, the use of UiO is subject to some limitations. First, the UiO driver is a character-driven driver and currently does not provide an interface to create user space block devices or network device drivers. In addition, DMA operations cannot be established in user space. However, for drivers that include only I/O memory access and simple interrupt handlers, the UiO interface is fully capable.
In the patch for the UiO interface, there is an example program in addition to the UiO core program. According to the author Thomasgleixner's experiment, if the drive is implemented in a fully loaded kernel, 68 different ioctl () commands are required, the entire drive length is more than 5000 lines, the corresponding user space code is more than 3000 lines, and if the driver in UiO mode is used, The kernel code is only 156 lines, and the user space code drops to within 3000 lines.

However, the important maintainer of the Linux kernel, Andrew Morton, also expressed some reservations about the use of UiO:
"I have some uncertainties about the whole idea of UiO, and I feel that we should encourage people to develop kernel drivers under the GPL license, rather than encourage them to develop user-space drivers of unfair open source code." These drivers tend to be slower, less reliable, and cannot be used across platforms. ”

In 2.6.23, the main documents related to UiO are as follows:
(1)/drivers/uio/uio.c
Core files of the UiO subsystem
(2)/DRIVERS/UIO/UIO_CIF.C
Hilscher CIF DeviceNet and Profibus card driver.

3, from DPDK analysis UiO Drive

UiO provides a framework for user-driven development, mainly due to the driver-dependent kernel functions and macros due to kernel version changes, resulting in the driver may also need to change, so instead of the user-driven to complete the task, which is similar to the Windows Hal mechanism, of course, HAL is the hardware abstraction layer.

How does the DPDK interact with the hardware?

Drivers in the DPDK need to periodically go to Poll/select/dev/uiox to check if the device is interrupted, not to send and receive data, and to operate the device's memory through MMAP. UiO framework itself to deal with the interruption of the device, interrupts can only be processed in the kernel state, UiO interrupt processing function is only to increase the count of interrupts.

Mmap can handle physical memory mappings, logical memory, and kernel virtual memory mappings. UiO also maps the memory of the device to the user space through Mmap, although the user state can also access the device memory through/SYS/CLASS/UIO/UIOX/MAPS/MAPX, so sending and receiving data is done by manipulating the device's memory.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Analysis on the advantages and disadvantages of UIO user driver driven by Linux device