I/O体系结构

I/O体系结构

虚拟文件系统利用底层函数,调用每个设备的操作,那么这些操作是如何在设备上执行的,操作系统又是如何知道设备的操作是什么的呢?这些是由操作系统决定的。
我们知道,操作系统的工作,是依赖于数据通路的,它们让信息得以在CPU、RAM、I/O设备之间传递。这些数据通路称为 总线。这就包括数据总线(PCI、ISA、EISA、SCSI等)、地址总线、控制总线。I/O总线,指的就是用于CPU和I/O设备之间通信的数据总线。I/O体系的通用结构如图所示:

那么CPU是如何通过I/O总线和I/O设备交互呢?这首先得从内存和外设的编址方式说起。第一种是“独立编址”,也就是内存和外设分开编址,I/O端口有独立的地址空间,这也被称为I/O映射方式。每个连接到I/O总线上的设备,都分配了自己的I/O地址集(在I/O地址空间中),它被称为I/O端口。inout等指令用语CPU对I/O端口进行读写。在执行其中一条指令时,CPU使用地址总线选择所请求的I/O端口,使用数据总线在CPU寄存器和端口之间传送数据。这种方式编码逻辑清晰,速度快,但空间有限。

第二种是“统一编址”,也被称为内存映射方式,I/O端口还可以被映射到内存地址空间(这也正是现代硬件设备倾向于使用的方式),这样CPU就可以通过对内存操作的指令,来访问I/O设备,并且和DMA结合起来。这种方式更加统一,易于使用。它实际上使用了ioremap()自从PCI总线出现后,不论采用I/O映射还是内存映射方式,都需要将I/O端口映射到内存地址空间

每个I/O设备的I/O端口都是一组寄存器:控制寄存器、状态寄存器、输入寄存器和输出寄存器。内核会纪录分配给每个硬件设备的I/O端口。

设备驱动程序模型

在内核中,设备不仅仅需要完成相应的操作,还要对其电源管理、资源分配、生命周期等等行为进行统一的管理。因此,内核建立了一个统一的设备模型,提取设备操作的共同属性,进行抽象,并且为添加设备、安装驱动提供统一的接口。它们本身并不代表具体的对象,只是用来维持对象间的层次关系。

这里首先要提的是sysfs文件系统。和/proc类似,安装于/sys目录,其目的是表现出设备驱动程序模型间的层次关系。在驱动程序模型当中,有三种重要的数据结构(旧版本),自上到下分别是subsystemksetkobject。如果要理解这个模型中,每个数据结构的作用,就必须理解它们和操作系统中的什么东西相对应。它们均对应着**/sys中的目录**。kobject是这个对象模型中,所有对象的基类。kset本身首先是一个kobject,而它又承担着一个kobject容器的作用,它把kobject组织成有序的目录;subsys则是更高的一层抽象,它本身首先是一个kset。驱动、总线、设备都能够用设备驱动程序模型中的对象表示。

设备驱动程序模型中的组件

设备驱动程序模型建立在几个基本数据结构之上,它们描述了总线、设备、设备驱动器等等。这里,我们来看看它们的数据结构。首先,device用来描述设备驱动程序模型中的设备。

struct device {
struct device		*parent;//父设备
struct kobject kobj;		//对应的kobject
const char		*init_name; //初始化名

const struct device_type *type;//设备的类型

struct mutex		mutex;	//驱动的互斥量

struct bus_type	*bus;		//设备在什么类型的总线
struct device_driver *driver;	//设备的驱动

void		*driver_data;	//驱动私有数据指针
struct dev_pm_info	power;
struct dev_pm_domain	*pm_domain;
//dma相关变量
u64		*dma_mask;			
u64		coherent_dma_mask;	
unsigned long	dma_pfn_offset;
struct device_dma_parameters *dma_parms;
struct list_head	dma_pools;	
struct dma_coherent_mem	*dma_mem; 

dev_t			devt;	//dev目录下的描述符
u32			id;	

spinlock_t		devres_lock;
struct list_head	devres_head;

struct klist_node	knode_class;
struct class		*class;	//类

void	(*release)(struct device *dev);//释放设备描述符时候的回调函数
};

首先,可以看到device中包含有一个kobject,还包含有它相关驱动对象。所有的device对象,全部收集在devices_kset中,它对应着/sys/devices中。设备的引用计数则是由kobject来完成的。device还会被嵌入到一个更大的描述符中,例如pci_dev,它除了包含dev之外,还有PCI所特有的一些数据结构。device_add完成了新的device的添加工作。我注意到,error = bus_add_device(dev);,也就是说device的添加会把它和bus关联起来。


再来看看驱动程序的结构。其数据结构为device_driver。相对于设备的数据结构来说,它相对较为简单:对于每个设备驱动,都有几个通用的方法,分别用语处理热插拔、即插即用、电源管理、探查设备等。同样,驱动也会被嵌入到一个更大的描述符中,例如pci_driver

struct device_driver {
const char		*name;		//驱动名
struct bus_type		*bus;	//总线描述符

struct module		*owner;
const char		*mod_name;	//模块名

bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */

const struct of_device_id	*of_match_table;
const struct acpi_device_id	*acpi_match_table;

int (*probe) (struct device *dev);		//探测设备
int (*remove) (struct device *dev);	//移除设备
void (*shutdown) (struct device *dev);	//断电方法
int (*suspend) (struct device *dev, pm_message_t state);//低功率
int (*resume) (struct device *dev);	//恢复方法
const struct attribute_group **groups;

const struct dev_pm_ops *pm;	//电源管理的操作

struct driver_private *p;
};

为什么这里没有kobject呢?它实际上保存在了driver_private当中,这个结构和device_driver是双向链接的。

struct driver_private {
struct kobject kobj;
struct klist klist_devices;
struct klist_node knode_bus;
struct module_kobject *mkobj;
struct device_driver *driver;
};  

driver的添加,通过调用driver_register()来完成,它同样包含一个函数:bus_add_driver(),也就是将driver添加到某个bus。


再来看看总线的结构。bus是连接device和driver的桥梁,bus中的很多代码,都是为了让device找到driver来设计的。总线的数据结构如下:

struct bus_type {
const char		*name;
const char		*dev_name;
struct device		*dev_root;
struct device_attribute	*dev_attrs;	/* use dev_groups instead */
const struct attribute_group **bus_groups;
const struct attribute_group **dev_groups;
const struct attribute_group **drv_groups;
//检查驱动是否支持特定设备
int (*match)(struct device *dev, struct device_driver *drv);	//回调事件,在kobject状态改变时调用
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
//探测设备
int (*probe)(struct device *dev);
//从总线移除设备
int (*remove)(struct device *dev);
//掉电
void (*shutdown)(struct device *dev);	

int (*online)(struct device *dev);
int (*offline)(struct device *dev);

//改变电源状态和恢复
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);

const struct dev_pm_ops *pm;

const struct iommu_ops *iommu_ops;

struct subsys_private *p;
struct lock_class_key lock_key;
};

同样,总线也有一个subsys_private,它保存了kobject。but_type中定义了一系列的方法。例如,当内核检查一个给定的设备是否可以由给定的驱动程序处理时,就会执行match方法。可以用bus_for_each_drv()bus_for_each_dev()函数分别循环扫描drivers和device两个链表中的所有元素,来进行match。

设备文件

设备驱动程序使得硬件设备,能以特定方式,响应控制设备的编程接口(一组规范的VFS函数,open,read,lseek,ioctl等),这些函数都是由驱动程序来具体实现的。在设备文件上发出的系统调用,都会由内核转化为对应的设备驱动程序函数,因此设备驱动必须被注册,也即构造一个device_driver,并且加入到设备驱动程序模型中。在注册时,内核会试图进行一次match。注意,这个注册的过程基本driver_register通常不会在驱动中直接调用,但我们但驱动通常都会间接的调用它来完成注册。

遵循linux“一切皆文件”的原则,I/O设备同样可以当作设备文件来处理,它和磁盘上的普通文件的交互方式一样,例如都可以通过write()系统调用写入数据。设备文件可以通过mknod()节点来创建,它们保存在/dev/目录下。

linux当中,硬件设备可以花费为两种:字符设备和块设备。其中,块设备指的是可以随机访问的设备,例如硬盘、软盘等;而字符设备则指的是声卡、键盘这样的设备。设备文件同样在VFS当中,但它的索引节点没有指向磁盘数据的指针,相反地它对应一个标识符(包含一个主设备号和一个次设备号)。VFS会在设备文件打开时,改变一个设备文件的缺省文件操作,让它去调用和设备相关的操作。

字符设备驱动程序

这里我们以字符设备驱动程序为例。首先,字符设备的驱动,在linux系统中,是以cdev结构来表示的:

struct cdev {
struct kobject kobj;
struct module *owner;
const struct file_operations *ops;
struct list_head list;	//包括的inode的devices
dev_t dev;
unsigned int count;
};

现在让我们回顾一下inode的数据结构:

struct inode {
	...
	union {
	struct pipe_inode_info	*i_pipe;
	struct block_device	*i_bdev;
	struct cdev		*i_cdev;
};
	...
}

我们看到了cdev指针的影子,可见cdev和inode确实是直接相关的。要实现驱动,首先就要对cdev进行初始化,注册字符设备。驱动的安装,首先要分配cdev结构体、申请设备号并初始化cdev。注意,驱动程序是如何和刚才我们所说的设备驱动模型建立联系的呢?实际上在初始化cdev的时候,就调用了kobject_init(),在模型中添加了一个kobject

随后,驱动要注册cdev,也即调用cdev_add()函数。这个工作主要是由kobj_map()来实现的,它是一个数组。对于每一类设备,都有一个全局变量,例如字符设备的cdev_map,块设备的bdev_map。最后要进行硬件资源的初始化。

int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
	int error;

	p->dev = dev;
	p->count = count;

	error = kobj_map(cdev_map, dev, count, NULL,
			 exact_match, exact_lock, p);
	if (error)
		return error;

	kobject_get(p->kobj.parent);

	return 0;
}  

kobj_map的结构如下,它用来保存设备号和kobject的对应关系

struct kobj_map {
	struct probe {
		struct probe *next;
		dev_t dev;
		unsigned long range;
		struct module *owner;
		kobj_probe_t *get;
		int (*lock)(dev_t, void *);
		void *data;
	} *probes[255];
	struct mutex *lock;
};

不过到现在为止,我们都还没有说明,程序在访问字符设备时,是如何去调用正确的方法的。我们曾提到过,open()系统调用会改变字符文件对象的f_op字段,将默认文件操作替换为驱动的操作。在字符设备文件创建时,会调用init_special_inode来进行索引节点对象的初始化。其inode的操作(def_chr_fops)只包含一个默认的文件打开操作,也即chrdev_open。它会根据inode,首先利用cdev_map,找到对应的kobject,随后再进一步找到cdev,然后从中提取出文件操作的函数fops,并把它填充到file当中去。

static int chrdev_open(struct inode *inode, struct file *filp)
{
	const struct file_operations *fops;
	struct cdev *p;
	struct cdev *new = NULL;
	int ret = 0;

	spin_lock(&cdev_lock);
	p = inode->i_cdev;
	if (!p) {
		struct kobject *kobj;
		int idx;
		spin_unlock(&cdev_lock);
		kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);//获取对应的kobject
		if (!kobj)
			return -ENXIO;
		new = container_of(kobj, struct cdev, kobj);
		spin_lock(&cdev_lock);
		/* Check i_cdev again in case somebody beat us to it while
		   we dropped the lock. */
		p = inode->i_cdev;
		if (!p) {
			inode->i_cdev = p = new;
			list_add(&inode->i_devices, &p->list);//将device加入到cdev的list中去
			new = NULL;
		} else if (!cdev_get(p))
			ret = -ENXIO;
	} else if (!cdev_get(p))
		ret = -ENXIO;
	spin_unlock(&cdev_lock);
	cdev_put(new);
	if (ret)
		return ret;

	ret = -ENXIO;
	fops = fops_get(p->ops)
	if (!fops)
		goto out_cdev_put;

	replace_fops(filp, fops);//替换file当中的fops  	
	return ret;
}

这里很奇怪的是,我们并没有看到类似前面提到的driver_register()device_register()这样的函数。实际上这里并没有真正创建一个设备,而只是说创建了一个接口,所以有这样一个这个问题:为什么cdev_add没有产生设备节点?对于这个问题,我们应该理解为cdevdriver/device二者是配套工作的,cdev用来和用户交互,而device则是内核中的结构。
另一个问题是,在上面的过程中,似乎没有提及设备文件的创建。实际上,作为一个rookie,那么设备文件常常是用 mknod命令手动创建的。当然,linux自然也提供了自动创建的借口,那就是利用udev来实现,调用device_create()函数。

当然,这个例子只是为了说明,操作系统的驱动程序是如何工作的,为什么对I/O设备的操作可以抽象成对设备文件的操作,程序在操作I/O文件时,是如何使用正确的操作的。

块设备的驱动

和字符设备类似,操作系统中的块设备,也是以文件的形式来访问。这里有一个很拗口的问题:磁盘是一个块设备,块设备有一个块设备文件。那么访问块设备文件和访问普通的磁盘上的文件有什么关系呢?
不论是块设备文件还是普通的文件,它们都是通过VFS来统一访问的。只不过对于一个普通文件,它可能已经在RAM中了(高速缓存机制),因此它的访问可能会直接在RAM中进行;但如果说要修改磁盘上的内容,或者文件内容不在RAM中,则也会间接地,通过块设备文件进行访问。这个驱动模型可以用这样一个图表示:

这里我们只考虑最底层的情况:内核从块设备读取数据。为了从块设备中读取数据,内核必须知道数据的物理位置,而这正是映射层的工作。映射层的工作包括两步:

  • 根据文件所在文件系统的块,将文件拆分成块,然后内核能够确定请求数据所在的块号;
  • 映射层调用文件系统具体的函数,找到数据在磁盘上的位置,也就是完成文件块号,到逻辑块号的映射关系。

随后的工作在通用块层进行,内核在这一层,启动I/O操作。通常一个I/O操作对应一组连续的块,我们把它称为bio,它用来搜集底层需要的信息。

I/O调度层负责根据内核中的各种策略,把待处理的I/O数据传送请求,进行归类。它的作用是把物理介质上相邻的数据请求,进行合并,一并处理。

最后一层也就是通过块设备的驱动来完成了,它向I/O接口发送适当的命令,从而进行实际的数据传送。

通用块层

通用块层负责处理所有块设备的请求,其核心数据结构就是bio。它代表一次块设备I/O请求

struct bio {
struct bio		*bi_next;		//请求队列中的下一个bio
struct block_device	*bi_bdev;	//块设备描述符指针
unsigned long		bi_flags;	/* status, command, etc */
unsigned long		bi_rw;		//rw位

struct bvec_iter	bi_iter;	

unsigned int		bi_phys_segments;//合并后有多少个段

unsigned int		bi_seg_front_size;
unsigned int		bi_seg_back_size;

atomic_t		bi_remaining;//剩余的bio_vec

bio_end_io_t		*bi_end_io;//bio结束的回调函数

void			*bi_private;

unsigned short		bi_vcnt;	//bio中biovec的数量

unsigned short		bi_max_vecs;//最多能有多少个

atomic_t		bi_cnt;		//结构体的使用计数

struct bio_vec		*bi_io_vec;	//bio_vec数组
};  

在这个数据结构中,还包含了一个bio_vec。这是什么意思呢?在linux中,相邻数据块被称为一个段,每个bio_vec对应一个内存页中的段。在io操作期间,bio是会一直更新的,其中的bi_iter用来在数组中遍历,按每个段来执行下一步的操作。

那么当通用块层收到一个I/O请求操作时,会发生什么呢?首先内核会为这次操作分配bio描述符,并对它进行填充。随后通用块层会调用generic_make_request,这个函数的作用很明确:它会进行一系列检查和设置,保证bio中的信息是针对整个磁盘,而不是磁盘分区的;随后获取这个块设备相关的请求队列q,调用q->make_request_fn,把bio插入请求队列中去。

I/O调度层

在块设备上,每个I/O请求操作都是异步处理的,通用块层的请求会被加入块设备的请求队列中,每个块设备都会单独地进行I/O的调度,这样能够有效提高磁盘的性能。

前面提到,通用块层会调用一个q->make_request_fn,向I/O调度程序发送一个请求,该函数会进一步调用__make_request()。这个函数的目的,就是把bio放进请求队列当中:(1)如果请求队列是空的,就构造一个新的请求插入;(2)如果请求队列不是空的,但是bio不能合并(不能合并到某个请求的头和尾),也构造一个新的请求插入;(3)请求队列不是空的,并且bio可以合并,就合并到对应的请求中去。注意,bio,请求和请求队列的关系如下:

-- request_queue
		|-- request1
				|-- bio0
		|-- request2
				|-- bio1
				|-- bio2

而I/O的调度,就是对请求队列进行排序,针对磁盘的特点,降低寻道的次数。这里说说几个常见的算法:

  • CFQ完全公平队列:默认的调度算法,完全公平排队。每个进程/线程都单独创建一个队列,并且用上面提到的策略进行管理。队列间采用时间片的方式来分配I/O。
  • Deadline最后期限算法:在电梯调度的基础上,根据读写请求的“最后期限”进行排序,并通过读期限短于写期限来保证写操作不被饿死。
  • 预期I/O算法:与最后期限类似,但是在读操作时,会预先判断当前的进程是否马上会有读操作,并且优先地进行处理。
  • NOOP:适用于固态硬盘,不进行任何优化。

总而言之,I/O调度层的作用,就是把请求的队列重新排序,并逐个交给块设备驱动程序进行处理。

块设备驱动程序

I/O调度层排序好的请求,会由块设备的驱动程序来处理。同样,块设备也遵循着我们前面提到的驱动程序模型:块设备对应一个device,而驱动程序对应了一个device_driver。对于块设备来说,驱动程序也要通过register_blkdev()注册一个设备号。随后,驱动程序要初始化gendisk描述符,以及它所包含的设备操作表fops。在此之后,是“请求队列”的初始化,以及中断程序的设置:要为设备注册IRQ线。最后要把磁盘注册到内核(add_disk),并把它激活。

当一个块设备文件被open()时,内核同样也要为它初始化操作。对于块设备来说,其默认的文件操作如下:

const struct file_operations def_blk_fops = {
.open		= blkdev_open,
.release	= blkdev_close,
.llseek		= block_llseek,
.read		= new_sync_read,
.write		= new_sync_write,
.read_iter	= blkdev_read_iter,
.write_iter	= blkdev_write_iter,
.mmap		= generic_file_mmap,
.fsync		= blkdev_fsync,
.unlocked_ioctl	= block_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl	= compat_blkdev_ioctl,
#endif
.splice_read	= generic_file_splice_read,
.splice_write	= iter_file_splice_write,
};

dentry_open()方法会调用blkdev_open()。它(1)首先会获取块设备的描述符:如果块设备已经打开,则可以通过inode->i_bdev直接获取,否则则需要根据设备号去查找块设备描述符。(2)获取块设备相关的gendisk地址,get_gendisk是通过设备号来找到gendisk的。(3)如果是第一次打开块设备,则要根据它是整盘还是分区,进行相应的设置和初始化。(4)如果不是第一次打开,只需要按需要执行自定义的open()函数就行了。

补充:I/O的监控方式

  • 轮询:CPU重复检查设备的状态寄存器,直到寄存器的值表明I/O操作已经完成了。
  • 中断:设备发出中断信号,告知I/O操作已经完成了,数据放在对应的端口,当数据缓冲满了时,由CPU去取,CPU需要控制数据传输的过程。
  • DMA:由CPU的DMA电路来辅助数据的传输,CPU不需要参与内存和IO之间的传输过程,只需要通过DMA的中断来获取信息。DMA能够在所有数据处理完时才通知CPU处理。



本文链接: http://home.meng.uno/articles/d0c0e94a/ 欢迎转载!

© 2018.02.08 - 2020.10.14 Mengmeng Kuang  保留所有权利!

UV : | PV :

:D 获取中...

Creative Commons License