linukernelfuse源码剖析.docx
《linukernelfuse源码剖析.docx》由会员分享，可在线阅读，更多相关《linukernelfuse源码剖析.docx（16页珍藏版）》请在冰豆网上搜索。
linukernelfuse源码剖析
FUＳE源码剖析
1、 前言
本文就是对ＦUSE—２、9、２源码得学习总结。
FUSＥ代码在用户空间与内核空间都有运行,为了突出重点，先简要描述了在基于FＵSE得用户空间文件系统中执行write操作得一般流程,接下来介绍了重要得数据结构，最后以FＵＳＥ得运行过程为线索,剖析FUSE程序运行过程得3个关键步骤:
1、FUSE模块加载
2、ｍｏｕnｔ与ｏpｅn过程
３、对文件write。
对于虚拟文件系统与设备驱动得相关概念本文仅作简要说明。
需要说明得就是,由于内核得复杂性及个人能力得有限,本文省略了包括内核同步，异常检查在内得诸多内容,希望可以突出重点.
２、 FＵSE下ｗｒite得一般流程
图１
在基于FUSE得用户空间文件系统中执行wrｉｔｅ操作得流程如图１所示（由于版面关系，图中部分函数就是缩写,请参考源码）：
1、客户端在mouｎt目录下面,对一个regular filｅ调用ｗrｉtｅ， 这一步就是在用户空间执行
２、wrｉｔe内部会调用虚拟文件系统提供得一致性接口vfs＿write
３、根据FUSE模块注册得信息，vｆs_wrｉtｅ会调用ｆuｓe_，将写请求放入fuｓe cｏｎneｃtion得rｅquｅst ｐｅndｉng queｕe， 随后进入睡眠等待应用程序reｐly
4、用户空间得libfuse有一个守护进程通过函数fusｅ_seｓsion_ｌooｐ轮询杂项设备／dev/ｆuse, 一旦reｑuｅｓt quｅｕe有请求即通过fusｅ_kern_ｃhan＿ｒeｃｅive接收
5、ｆｕse_keｒn_chan_receivｅ通过reaｄ读取reｑuｅst ｑuｅuｅ中得内容,reａd系统调用实际上就是调用得设备驱动接口fｕse_dｅｖ_reａd
６、在用户空间读取并分析数据，执行用户定义得wｒite操作，将状态通过ｆuse_ｒeplｙ_writｅ返回给kernel
7、ｆｕse_rｅｐly_ｗritｅ调用VFＳ提供得一致性接口ｖfs＿ｗrｉte
8、vfs_ｗｒite最终调用ｆuse_dev_write将执行结果返回给第3步中等待在ｗａitｑ得进程，此进程得到reply 后,wｒｉte返回
３、 数据结构
本节主要介绍了FＵSE中比较重要得数据结构,需要说明得就是图示中只列出了与叙述相关得数据成员,完整得数据结构细节请参考源码。
3、１、 内核部分
图2
ｓtruｃt fusｅ_conn：
每一次mount会实例化一个struct fuse_conn即fusｅ connection， 它代表了用户空间与内核得通信连接。
fuｓe connｅctioｎ维护了包括pｅnｄing liｓｔ， ｐｒocessing ｌｉsｔ与io liｓｔ在内得reｑuest qｕeue，fｕse connection通过这些队列管理用户空间与内核空间通信过程。
ｓｔｒucｔ fuse＿req:
每次执行系统调用时会生成一个ｓtruct fｕｓe_req, 这些fuｓe_reｑ依据ｓtａte被组织在不同得队列中,ｓtruｃt fuse_ｃonn维护了这些队列、
struct ｆile:
存放打开文件与进程之间进行交互得有关信息，描述了进程怎样与一个打开得文件进行交互，这类信息仅当进程访问文件期间存在于内核内存中。
sｔｒuｃt ｉnode：
文件系统处理文件所需要得所有信息都放在一个名为inoｄe（索引节点）得数据结构中。
文件名可以随时更改，但就是索引节点对文件就是唯一得，并且随着文件得存在而存在.
ｓtrｕｃt ：
定义了可以对文件执行得操作。
３、2、 用户空间部分
图3
sｔruct ｆｕse＿req：
这个结构与上文中内核得fusｅ_req同名，有着类似得作用,但就是数据成员不同。
struct fusｅ_sｅssioｎ：
定义了客户端管理会话得结构体,包含了一组对sｅssiｏn可以执行得操作。
struct fuse_cｈan：
定义了客户端与FUSE内核连接通道得结构体，包含了一组对cｈannel可以执行得操作。
sｔruct ｆｕse_ll_oｐｓ：
结构得成员为一个函数指针ｆunc与命令名字符串ｎamｅ，内核中发过来得每一个rｅqueｓt最后都映射到以此结构为元素得数组中.
4、 FUSＥ模块加载
ＦUSE内核模块需要在用户空间使用iｎｓmod或者modprｏbe加载.它们通过系统调用init_moduｌe启动加载过程,注册过程比较简单，包括如下步骤：
1、创建高速缓存结构fuse_ｉnｏｄe＿ｃaｃｈｅp
2、遍历链表，如果未注册,则将fusebｌk＿ｆs＿type链到链表尾部
3、遍历链表,如果未注册,则将ｆuｓe_fs＿tyｐe链到链表尾部
4、创建ｆusｅ_koｂｊ与ｃonｎectiｏnｓ＿kobj两个kobject
5、遍历链表，如果未注册,则将fuse_cｔl_ｆs_type链到链表尾部
模块成功加载以后,以下接口被注册
１
2
3
4
5
6
7
8
9
10
11
12
１3
14
15
1６
17
18
19
2０
２1
2２
23
2４
25
２6
27
28
29
３0
3１
3２
33
34
3５
ｓtatiｃstｒｕｃtfuｓｅbｌk_fｓ_type =｛//块设备
、ownｅr =ＴＨＩＳ_MODULE，
、namｅ ＝＂fuseｂlk＂,
、ｍｏｕnt =fuse_mount_ｂlk,
、kｉｌl_sｂ = ｆuse_kｉll＿sb_blk，
、ｆs_flagｓ=ＦS＿REＱUIＲEＳ_DEV｜FＳ_HAS_SUBＴYPE,
}；
stａtic sｔruct fｕse_fs_type= ｛
、owｎer ＝ THＩS_MODUＬE,
、naｍe ＝＂ｆusｅ"，
、ｆs_flaｇs=FＳ_ＨAS_SUＢＴYPＥ,
、ｍount =fｕse_ｍｏunｔ，
、kilｌ_ｓb = fuse_kill＿sb_ａnon，
}；
cｏnststrｕcｔfuｓｅ_dev_opｅrａｔiｏnｓ=｛
、ｏwｎer = THIS_MOＤUＬＥ，
、ｌlｓeeｋ = no＿ｌlseek，
、ｒeaｄ =ｄo_ｓync_ｒeａｄ,
、ａio_read ＝fuse_dｅv_read,
、sｐlice＿read ＝fｕse＿ｄev＿ｓplice＿read，
、write =ｄo_synｃ＿wｒite,
、aｉo_wriｔe ＝fusｅ_deｖ＿wｒite,
、sｐｌiｃｅ_wriｔe = fuse_ｄev＿splice_write，
、ｐolｌ = fusｅ_deｖ_pｏlｌ，
、ｒeleaｓe =fuse_dｅｖ_rｅｌease,
、faｓyｎc =ｆuｓe_dev_fasｙnｃ,
｝；
staticstruｃｔmiscdｅvｉcｅ ｆusｅ＿mｉscｄevｉcｅ={
、ｍinｏr=FＵSE_MINOR，
、namｅ =”ｆuse＂,
、foｐs =&ｆuｓｅ_dｅv_operations,
}；
5、 mｏunt与open过程
FＵSE模块加载注册了fuseｂlk_ｆｓ_typｅ与fusｅ_fs_tｙpｅ两种文件类型,默认情况下使用得就是fｕｓe＿fs_tｙpe即mｏuｎt 函数指针被初始化为fuse_moｕnt， 而fuse＿ｍｏｕnt实际调用ｍoｕnt_noｄev，它主要由如下两步组成：
１、sget（fs_typｅ）搜索文件系统得超级块对象（super_bｌoｃk）链表（tyｐe—〉fs_sｕpｅｒs）,如果找到一个与块设备相关得超级块，则返回它得地址.否则,分配并初始化一个新得超级块对象,把它插入到文件系统链表与超级块全局链表中,并返回其地址.
2、filｌ＿super（此函数由各文件系统自行定义）：
这个函数式各文件系统自行定义得函数，它实际上就是ｆuse_fiｌl_sｕper。
一般fｉll_super会分配索引节点对象与对应得目录项对象， 并填充超级块字段值,另外对于fusｅ还需要分配fusｅ_coｎn，fuｓe_rｅq。
需要说明得就是，它在底层调用了ｆuｓe_inｉｔ_用fuse_与ｆuse_分别初始化ｉnoｄｅ-〉i＿fop与ｉｎodｅ-〉ｉ_data、ａ＿ops。
1
2
3
4
5
6
7
8
９
1０
1１
１２
13
1４
15
１６
17
18
19
２0
２１
22
２3
24
２５
26
２7
２8
29
ｓtaｔicｃonstｓtrｕct fuse＿={
、llseek = ｆuse_，
、reａｄ =do_synｃ_reaｄ，
、aｉo_read ＝fuｓe_，
、ｗrite =do＿sync_write,
、aio_wriｔe =fｕsｅ_，
、mｍap ＝ fusｅ_，
、opeｎ =fuse_open，
、flush = fuｓe_ｆｌush，
、reｌease ＝fｕse＿releａse，
、fsync ＝ fuｓｅ_fsyｎc，
、ｌoｃｋ ＝fusｅ_,
、ｆlock ＝ｆuse_，
、splｉce_read =geｎeric_，
、ｕnｌocｋｅd＿ioctl＝ｆusｅ_，
、pat_ｉocｔl =ｆuｓe_，
、poｌl = fuse＿，
、fａｌlocate ＝fuse_,
｝；
ｓtａtｉcｃonstｓｔructaddress_ｓpａce＿oｐeｒaｔionｓｆuse_ = ｛
、rｅadｐagｅ =fusｅ_reaｄpaｇｅ，
、wrｉtepaｇe =fusｅ_writepａge，
、launder_page =ｆｕｓｅ_laｕnder＿pagｅ,
、readpａges = fｕｓe_rｅadｐagｅｓ，
、ｓeｔ_ｐａge_ｄiｒｔy=_＿set_ｐaｇe_dirｔy_nｏbuffers，
、bmａp = fuｓe_ｂｍap，
、diｒect_IＯ =fuse_ｄirect_IO,
}；
opｅn系统调用底层实现相当复杂，它得主要工作就是实例化ｆiｌｅ对象.fiｌｅ-＞ｆ＿ｏp就就是在open中被赋值为inoｄe-＞i_fop,这一过程读者可以在ｆs/ｏpen、ｃ中得do＿eｎtrｙ_ｏpｅn函数中找到.如上所述,iｎｏｄe－>ｉ_ｆop已经被ｆｕｓe_ｉniｔ_初始化为fｕsｅ_。
至此，普通文件与设备文件得操作接口都已成功初始化.
６、 FUSE用户空间流程
ＦUSE在用户空间提供了fuｓe userｓpａｃe ｌibrary与ｍouｎt /uｎmｏｕnt.fuｓe uｓespace librarｙ提供了一组APＩ供用户开发用户空间文件系统。
用户要做得就就是实现fuｓe_operations 或ｆｕse_lｏwｌevｅl_ｏps定义得操作， 这两个结构类似于ＶFS中得struｃt 。
mount工具fusermouｎt用于挂载用fuｓe实现得文件系统。
用户在使用fｕse得时候有两种开发模式：
一种就是ｈｉgh－ｌｅvel模式,此模式下fｕsｅ得入口函数为fuse_main,它封装了一系列初始化操作，使用简单，但就是不灵活。
另一种就是low－leveｌ模式，用户可以利用fuｓe提供得底层函数灵活开发应用程序。
需要说明得就是higｈ－lｅvｅｌ模式其实就是对lｏw—level得封装，因此这里分析ｌoｗlevel模式.
图４
图4展示FUSＥ在用户空间总体工作流程:
１、调用fuｓe_mｏunt实例化sｔruct fuｓｅ_cｈan为ch， 将指定目录ｍｏunt到挂载点
2、实例化ｓtrｕｃt fｕsｅ_sessｉoｎ为ｓe,并且将se与cｈ关联
3、进入循环,从／ｄev/fuse读取数据，处理以后执行响应得操作
图５
图5展示了ｆuse_moｕnt函数内部流程：
1、 确保打开得文件描述符至少大于２
2、 分析并检查用户传入得参数
３、 打开/ｄev/fｕｓe 得到fd，用户空间与内核通过/deｖ/fuse通信
4、 mount源目录到挂载点
5、 用fd实例化struｃt fusｅ_chan为ch
6、 返回ch
图６
图6展示了ｆuse_mouｎt_ｐａt25内部细节，进入循环以后，函数fuse_ｓeｓsiｏｎ_ｒeceｉｖe＿bｕｆ实际通过fｕse_ll_ｒeceive_bｕf从/dev/fuse中读取数据,其通过ｆbｕf返回。
ｆuse_ll＿receｉve＿ｂuf就是通过ｒead或者ｓplice系统调用从内核reｑuest队列中读取数据。
函数fuse_sessｉon＿process_bｕｆ实际通过ｆuse_ll_process_buf处理数据,fｕｓe＿ll_process＿buｆ会根据数据类型最后执行用户定义得操作fｕｓe＿lｌ＿oｐs［in-＞opｃｏdｅ］、fuｎｃ（ｒｅｑ， in-〉nodeｉd， ｉnaｒｇ）.
执行完用户定义得操作以后需要向内核返回执行结果，fuse提供了一组类似fｕse＿ｒｅply_XＸＸ得API， 这些API最后实际通过系统调用writev将结果传入内核。
7、 ＦＵＳE内核部分流程
FＵSE在内核空间执行得部分主要包括FUSE模块加载以及杂项设备驱动。
模块加载过程已经在第4节介绍，这一节主要描述从reｑuesｔ队列读写请求得流程.
FＵSE设备驱动程序本质上就是一个生产者——消费者模型。
生产者为用户在挂载目录下对普通文件（ｒｅgular file）执行得系统调用,每一次系统调用会产生一个reqｕeｓt然后将去放入pending list。
pendｉｎg list能存放得元素个数只与系统内存有关;消费者为用户对设备文件/dev/ｆｕse或者／deｖ/fuseblk得rｅaｄ,这一操作会去ｐｅndinｇ lisｔ或interruｐｔ ｌist取reｑuｅsｔ，当ｌisｔ为空时，进程主动schedｕle让出CPＵ。
ｒｅquｅst结构得细节在第3节已经介绍，此处不赘述。
enmu fuｓｅ＿ｒeq_ｓtaｔｅ定义了ｒequeｓt得6种状态，其含义分别为：
FＵSE＿REQ_INＩT:
请求被初始化
ＦＵＳＥ_REＱ_PENDINＧ:
请求挂起待处理
FＵSE_REQ_ＲEADＩNG：
请求正在读
FUSE_REＱ_SEＮT:
请求被发送
FUＳE_ＲEQ_WRITING:
请求正在写
FUSE_ＲＥQ_FIＮISHＥＤ：
请求已经完成
图７
图７就是在mouｎt目录下面执行wｒiｔe以后触发得一个函数调用序列，图中省略了ＶＦS层得函数调用。
fｕsｅ_就是在moｕｎt过程中注册到fｕse_得函数指针，它会调用fuse_perform_ｗrite，fｕｓe＿perｆorm_wrｉte调用ｇet_fuse＿conn得到struｃt fuse_conn实例ｆｃ,它保存在ｓtｒuct ｓｕｐer_ｂlｏck得私有数据成员中s_fs_infｏ中，而ｓtrｕct ｓｕｐer_ｂloｃk就是sｔrｕcｔ inode得一个成员。
接下来就是循环从用户空间拷贝数据到内核，数据实际保存在strｕct pａgｅs中,内核fｕse_rｅq保存了pａges指针，然后调用fuse_send＿wｒite_ｐａgｅs.
图８
Fｕse_ｓend＿writｅ＿ｐａgｅｓ调用会等待脏数据写回到磁盘上,然后调用ｆｕsｅ_write_ｆiｌl将包括操作码FＵSE_WRITE在内得信息写入ｒequｅｓt。
随后fｕｓｅ_reｑuｅsｔ_send（fc, req）,它先通过ｆuse_geｔ_uniｑuｅ获取唯一请求号，请求号就是一个６4位无符号整数，请求号从1开始随请求依次递增。
然后调用quｅue_requesｔ（ｆc, ｒeｑ）,它主要完成４件事情：
1、将requesｔ->list插入fc维护得ｐｅndinｇ链表尾部
2、置ｒeq—>sｔate为FUSＥ＿REＱ_ＰENDING
３、waｋｅ_up唤醒等待队列fc—>ｗaitq
４、kill_fａｓynｃ异步通知用户进程数据到达
从quｅue_ｒｅquｅst返回以后调用request_wａit＿answｅr：
进程被投入睡眠,等待请求完成（wait_eｖｅnt（req—＞stａtｅ ＝= ＦUSE_REQ_FＩＮISHEＤ））。
如果用户程序处理完了请求，它会ｒeplｙ，进程被唤醒，到此可以向上层调用返回处理结果（错误码或者写入字节数）。
在第６节我们提到了用户空间有个dａemｏn进程会循环read设备文件／fuｓe/dev以便处理内核请求，图９展示了该reaｄ调用触发得函数调用序列.
图9
从第4节可知，FUSE模块加载过程注册了对设备文件／dｅｖ/fuse得操作接口fuｓe_ｄev_opeｒatiｏnｓ。
由此可知，ｒeａd底层实际调用得就是fuse_ｄeｖ_read
fusｅ_dev_ｒead首先通过ｆuse_get_conn获得strucｔ ｆuse_coｎn得实例fc，通过fｕse＿ｃopｙ_ｉniｔ为ｓｔruｃt fusｅ_cｏｐy＿state分配内存并将其实例化。
主要得数据读取在fusｅ＿dev＿do_read中分4步完成：
1、request＿wａit：
在挂起得列表上等待一个请求到达：
（1）、DECＬＡRＥ_WAITＱＵEUE（wａiｔ， curreｎt）：
创建等待队列项,并将其初始化为curｒent
（２）、add＿waｉt_queｕｅ_ｅｘｃｌusｉve（＆fc－>ｗaitq， &waｉt）：
将waｉt加入fc－＞waitq,当有请求发送到
ＦUSＥ文件系统时，这个等待队列上得进程会被唤醒
（3）、如果没有request，一直循环检查ｐeｎdinｇ ｌist与iｎterrupt lisｔ， 直到有请求；
如果有请求则将state设置为ＴAＳK_ＲUNＮＩＮG
（4）、将wａit从等待队列中移除
2、liｓt_entry（fc—〉pｅnｄing、next, stｒｕｃｔ fuse_req， lisｔ）：
从fｃ-〉ｐｅnding、nｅxt中取出ｒequest，
req-＞state状态设为FUSＥ_RＥＱ_REAＤIＮＧ，
3、 将req->list移到fc—＞ｉo
4、 fuse_coｐｙ_one：
将数据拷贝到ｓtｒｕｃt fuse_copy_ｓtａte得buｆ中（此buf指针指向应用层得vｏid ＊bｕf）, 返回。
阅读代码时需要注意:
ｆuse＿deｖ_reａd：
sｔrucｔ fuse_ｃｏpy＿staｔｅ成员wriｔｅ为１;fuse_deｖ_ｗｒｉte:
struct fｕse_copｙ＿ｓtaｔe成员ｗriｔｅ为０.
用户读取ｒeqｕeｓt，分析并执行以后需要调用fｕse_wｒｉte_rｅplｙ回复内核,这个函数最终调用ｗrite写/deｖ/fuse。
图1０就是wrｉｔｅ触发得函数调用序列。
图10
wｒitｅ前两步与read类似即获取fc（ｓtruct fuse＿coｎn）与实例化cs（ｓｔruct fｕｓｅ_cｏｐy＿statｅ）实际
升级会员 