UIO 子系统结构介绍

╰半夏微凉° 2022-08-07 02:34 253阅读 0赞

**------1------为什么出现了UIO？**

硬件设备可以根据功能分为网络设备，块设备，字符设备，或者根据与CPU相连的方式  
分为PCI设备，USB设备等。它们被不同的内核子系统支持。这些标准的设备的驱动编写  
较为容易而且容易维护。很容易加入主内核源码树。  
但是，又有很多设备难以划分到这些子系统中，比如I/O卡，现场总线接口或者定制的FPGA。  
  
通常这些非标准设备的驱动被实现为字符驱动。这些驱动使用了很多内核内部函数和宏。  
而这些内部函数和宏是变化的。这样驱动的编写者必须编写一个完全的内核驱动，而且一直维护  
这些代码。而且这些驱动进不了主内核源码。于是就出现了用户空间I/O框架(Userspace I/O framework)。

**---------2----------UIO 是怎么工作的？**

一个设备驱动的主要任务有两个：  
1. 存取设备的内存  
2. 处理设备产生的中断  
  
对于第一个任务，UIO 核心实现了mmap()可以处理物理内存(physical memory)，逻辑内存(logical memory)，  
虚拟内存(virtual memory)。UIO驱动的编写是就不需要再考虑这些繁琐的细节。  
  
第二个任务，对于设备中断的应答必须在内核空间进行。所以在内核空间有一小部分代码  
用来应答中断和禁止中断，但是其余的工作全部留给用户空间处理。  
  
如果用户空间要等待一个设备中断，它只需要简单的阻塞在对 /dev/uioX的read()操作上。  
当设备产生中断时，read()操作立即返回。UIO 也实现了poll()系统调用，你可以使用  
select()来等待中断的发生。select()有一个超时参数可以用来实现有限时间内等待中断。  
  
对设备的控制还可以通过/sys/class/uio下的各个文件的读写来完成。你注册的uio设备将会出现在该目录下。  
假如你的uio设备是uio0那么映射的设备内存文件出现在 /sys/class/uio/uio0/maps/mapX，对该文件的读写就是  
对设备内存的读写。

如下的图描述了uio驱动的内核部分，用户空间部分，和uio 框架以及内核内部函数的关系。

![0_1315147328XXZ9.gif][]

Figure 1: uio\_architecture  
  
详细的UIO驱动的编写可以参考 drivers/uio/下的例子，以及Documentation/DocBook/uio-howto.tmpl  
//tmpl格式的文件可以借助 docbook-utils (debian下)工具转化为pdf或者html合格等。  
  
 **---------3----------- “uio 核心的实现 和 uio驱动的内核部分的关系“详谈**  
重要的结构：  
struct uio\_device \{  
struct module \*owner;  
struct device \*dev; //在\_\_uio\_register\_device中初始化  
int minor; // 次设备id号，uio\_get\_minor  
atomic\_t event; //中断事件计数  
struct fasync\_struct \*async\_queue;//该设备上的异步等待队列//  
// 关于 “异步通知“ //参见LDD3第六章  
wait\_queue\_head\_t wait; //该设备上的等待队列，在注册设备时(\_\_uio\_register\_device)初始化  
int vma\_count;  
struct uio\_info \*info;// 指向用户注册的uio\_info，在\_\_uio\_register\_device中被赋值的  
struct kobject \*map\_dir;  
struct kobject \*portio\_dir;  
\};  
  
/\*  
\* struct uio\_info - UIO device capabilities  
\* @uio\_dev: the UIO device this info belongs to  
\* @name: device name  
\* @version: device driver version  
\* @mem: list of mappable memory regions, size==0 for end of list  
\* @port: list of port regions, size==0 for end of list  
\* @irq: interrupt number or UIO\_IRQ\_CUSTOM  
\* @irq\_flags: flags for request\_irq()  
\* @priv: optional private data  
\* @handler: the device's irq handler  
\* @mmap: mmap operation for this uio device  
\* @open: open operation for this uio device  
\* @release: release operation for this uio device  
\* @irqcontrol: disable/enable irqs when 0/1 is written to /dev/uioX  
\*/  
struct uio\_info \{  
struct uio\_device \*uio\_dev; // 在\_\_uio\_register\_device中初始化  
const char \*name; // 调用\_\_uio\_register\_device之前必须初始化  
const char \*version; //调用\_\_uio\_register\_device之前必须初始化  
struct uio\_mem mem\[MAX\_UIO\_MAPS\];  
struct uio\_port port\[MAX\_UIO\_PORT\_REGIONS\];  
long irq; //分配给uio设备的中断号，调用\_\_uio\_register\_device之前必须初始化  
unsigned long irq\_flags;// 调用\_\_uio\_register\_device之前必须初始化  
void \*priv; //  
irqreturn\_t (\*handler)(int irq, struct uio\_info \*dev\_info); //uio\_interrupt中调用，用于中断处理  
// 调用\_\_uio\_register\_device之前必须初始化  
int (\*mmap)(struct uio\_info \*info, struct vm\_area\_struct \*vma); //在uio\_mmap中被调用，  
// 执行设备打开特定操作  
int (\*open)(struct uio\_info \*info, struct inode \*inode);//在uio\_open中被调用，执行设备打开特定操作  
int (\*release)(struct uio\_info \*info, struct inode \*inode);//在uio\_device中被调用，执行设备打开特定操作  
int (\*irqcontrol)(struct uio\_info \*info, s32 irq\_on);//在uio\_write方法中被调用，执行用户驱动的  
//特定操作。  
\};

先看一个uio 核心和 uio 设备之间关系的图，有个整体印象：

![0_1315147232n650.gif][]

**Figure 2: uio\_core\_device**

uio核心部分是一个名为"uio"的字符设备(下文称为“uio核心字符设备“)。用户驱动的内核部分  
使用uio\_register\_device向uio核心部分 注册uio设备。uio 核心的任务就是管理好这些注册的uio  
设备。这些uio设备使用的数据结构是 uio\_device。而这些设备属性，比如name, open(),  
release()等操作都放在了uio\_info结构中，用户使用 uio\_register\_device注册这些驱动之前  
要设置好uio\_info。  
uio核心字符设备注册的  
uio\_open  
uio\_fasync  
uio\_release  
uio\_poll  
uio\_read  
uio\_write  
中除了完成相关的维护工作外，还调用了注册在uio\_info中的相关方法。比如，在  
uio\_open中调用了uio\_info中注册的open方法。  
那么这里有一个问题，uio核心字符设备怎么找到相关设备的uio\_device结构的呢？  
这就涉及到了内核的idr机制，关于该机制可以参考：  
http://blog.csdn.net/ganggexiongqi/article/details/6737389  
在uio.c中，有如下的定义：  
static DEFINE\_IDR(uio\_idr);  
/\* Protect idr accesses \*/  
static DEFINE\_MUTEX(minor\_lock);  
在你调用uio\_register\_device(内部调用了\_\_uio\_register\_device)注册你的uio 设备时，  
在\_\_uio\_register\_device中调用了uio\_get\_minor函数，在uio\_get\_minor函数中，利用  
idr机制(idr\_get\_new)建立了次设备号和uio\_device类型指针之间的联系。而uio\_device指针  
指向了代表你注册的uio设备的内核结构。在uio核心字符设备的打开方法，uio\_open中  
先取得了设备的次设备号(iminor(inode))，再次利用idr机制提供的方法(idr\_find)取得了  
对应的uio\_device类型的指针。并且把该指针保存在了uio\_listener结构中，以方便以后  
使用。  
  
**----4---关于设备中断的处理**  
  
在\_\_uio\_register\_device中，为uio设备注册了统一的中断处理函数uio\_interrupt,  
在该函数中，调用了uio设备自己提供的中断处理函数handler(uio\_info结构中)。  
并调用了uio\_event\_notify函数对uio设备的中断事件计数器增一, 通知各个读进程  
“有数据可读”。每个uio设备的中断处理函数都是单独注册的。  
  
 **关于中断计数**: uio\_listener  
struct uio\_listener \{  
struct uio\_device \*dev; // 保存uio设备的指针，便于访问  
s32 event\_count; //跟踪uio设备的中断事件计数器  
\};  
对于每一个注册的uio 设备(uio\_device), 都关联一个这样的结构。  
它的作用就是跟踪每个uio设备(uio\_device)的中断事件计数器值。  
  
在用户空间进行文件打开操作(open)时，与uio设备关联的uio\_listener结构就被分配，  
指向它的指针被保存在filep指针的private\_data字段以供其他操作使用。  
在用户空间执行文件关闭操作时，和uio设备关联的uio\_listener结构就被销毁。  
  
在uio设备注册时，uio core会为设备注册一个通用的中断处理函数(uio\_interrupt),  
在该函数中，会调用uio设备自身的中断处理函数(handler). 中断发生时，  
uio\_event\_notify将被调用，用来对设备的中断事件计数器()增一，并通知各读进程，  
有数据可读。  
  
uio\_poll 操作判断是否有数据可读的依据就是 listener中的中断事件计数值  
(event\_count)和uio设备中的中断事件计数器值不一致(前者小于后者)。因为  
listener的值除了在执行文件打开操作时被置为被赋值外，只在uio\_read操作中  
被更新为uio设备的中断事件计数器值。  
  
疑问1：  
对于中断事件计数器，uio\_device中定义为 atomic\_t 类型，又有  
typedef struct \{  
int counter;  
\} atomic\_t;  
需不需要考虑溢出问题？  
同样的问题存在在uio\_listener的event\_count字段。  
  
关于uio\_device的event字段 uio\_howto中：  
event: The total number of interrupts handled by the driver since the last time the device node  
was read.  
【如果中断事件产生的频率是100MHZ的话，(2^32)/(10^8) = 42 秒 】counter计数器就会  
溢出。所以，依赖于counter的操作可能会出现问题。//补充：中断发生的频率最多为kHz不会是 Mhz，所以\[\]中的假设是不合理的，但是溢出会发生，而且，依赖counter值的应用可能会出现问题！！  
  
我们可以添加一个timer，在timer 处理函数中，调用uio\_event\_notify增加counter的值，  
很快会观察到溢出。<<<<<<< 例子，还没有写 (^\_^)  
//其实，可以在我们注册的函数中，得到uio\_device的指针，可以直接修改event的值。  
  
  
===========关于 sysfs文件创建  
sysfs下uio相关的文件结构如下

**\[plain\]** [view plain][] [copy][view plain]

1.   sys 
2.   ├───uio 
3.   ├───uio0 
4.   │ ├───maps 
5.   │ ├───mapX 
6.   ├───uio1 
7.   ├───maps 
8.   │ ├───mapX 
9.   ├───portio 
10.  ├───portX

其中的uio是uio模块加载时，uio\_init调用init\_uio\_class调用class\_register注册到内核空间的。  
关于这个类的方法有个疑问，就是比如在show\_event方法中，  
struct uio\_device \*idev = dev\_get\_drvdata(dev);//具体的uio设备相关的信息  
这个uio\_device相关的信息是怎么跟 uio class联系上的?  
在调用\_\_uio\_register\_device注册uio设备时，通过  
  
idev->dev = device\_create(&uio\_class, parent,  
MKDEV(uio\_major, idev->minor), idev,  
"uio%d", idev->minor);  
其中，idev就是 uio\_device类型的指针，它作为drvdata被传入，  
device\_create调用了device\_create调用了device\_create\_vargs调用了dev\_set\_drvdata。  
这样在uio class的 show\_event方法中，就可以使用  
struct uio\_device \*idev = dev\_get\_drvdata(dev);  
得到了uio设备的结构体的指针。  
  
device\_create调用完毕后在 /sys/class/uio/下就会出现 代表uio设备的uioX文件夹，  
其中X为uio设备的次设备号。  
  
往下，就不再啰嗦了。希望有所帮助。  
=======================================  
***参考：  
1，2 参考了Userspace I/O drivers in a realtime context Hans J. Koch, Linutronix GmbH  
3，4 参考了 uio.c 分析 http://blog.csdn.net/ganggexiongqi/article/details/6737647***

*  上一篇[vm\_area\_struct][vm_area_struct]
 *

[0_1315147328XXZ9.gif]: /images/20220805/0b80c3a88c324513b9bef1004286c3e1.png
[0_1315147232n650.gif]: /images/20220805/6949f0bbf0aa4e39a572c7f5692a21ab.png
[view plain]: http://blog.csdn.net/ganggexiongqi/article/details/6748103#
[vm_area_struct]: http://blog.csdn.net/ganggexiongqi/article/details/6746248