Linux Device Drivers

层次结构

在了解驱动程序的具体内容之前，我们可以首先从 Nvidia GPU 所提供的一些 API 层级入手来理解整体的结构，下图展示了上层应用程序在使用 cudaMalloc 时的调用流程图，其中的重点就是 Runtime API, Driver API 和 驱动程序。

sequenceDiagram
    participant App
    participant RuntimeAPI
    participant DriverAPI
    participant KernelDriver
    participant GPU

    App->>RuntimeAPI: cudaMalloc(&d_A, size)
    RuntimeAPI->>DriverAPI: cuMemAlloc(&d_A, size)
    DriverAPI->>KernelDriver: ioctl(NV_IOCTL_MEM_ALLOC)
    KernelDriver->>GPU: 配置GPU MMU页表
    GPU-->>KernelDriver: 返回物理地址
    KernelDriver-->>DriverAPI: 虚拟地址映射
    DriverAPI-->>RuntimeAPI: 成功状态
    RuntimeAPI-->>App: 返回d_A

从这个调用顺序图中，我们就可以看出不同层次 API 大概的实现方式（以下代码并不代码真实实现，仅用于表述大致的实现逻辑），如下方代码所示，Runtime API 在实现时会调用 Driver API，Driver API 在实现时则会调用 ioctl，驱动程序则是完成了一些 ioctl 信号对应的具体逻辑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// Runtime API 
cudaError_t cudaMalloc(void** devPtr, size_t size) {
    __cuda_init(); // 懒初始化
    CUdeviceptr ptr;
    CUresult res = cuMemAlloc(&ptr, size); // 调用Driver API
    *devPtr = (void*)ptr;
    return (res == CUDA_SUCCESS) ? cudaSuccess : cudaErrorMemoryAllocation;
}

// Driver API
CUresult cuMemAlloc(CUdeviceptr* dptr, size_t bytes) {
    struct nv_mem_request req = { .size = bytes };
    ioctl(g_fd, NV_IOCTL_MEM_ALLOC, &req); // 调用内核驱动
    *dptr = req.phys_addr;
}

// Driver
long nvidia_ioctl(struct file* filp, unsigned int cmd, unsigned long arg) {
    switch (cmd) {
        case NV_IOCTL_MEM_ALLOC: {
            struct nv_mem_request req;
            copy_from_user(&req, (void*)arg, sizeof(req));
            
            // 操作GPU MMU页表
            uint64_t phys_addr = gpu_mmu_alloc(req.size); 
            req.phys_addr = phys_addr;
            
            // 返回用户态可映射的虚拟地址
            copy_to_user((void*)arg, &req, sizeof(req));
            break;
        }
    }
}

从这里的伪代码我们可以发现一个问题，即 Runtime API 和 Driver API 的实现过程都存在明确可调用其他API，但是 driver 已经属于软件层中的最底层了，下层就直接同硬件对接了，它在实现时该如何处理才能做到同硬件的交互。

之所以产生这个疑问，是因为有一个错误理解，即“driver 已经属于软件层中的最底层了“。实际上在 driver 之下，还存在着内核代码这样一层软件，它才是直接对接硬件的最下层软件。所以 driver 在实现时也是存在可调用的 API 的，即 Linux 内核原生 API。

那么问题就变为了通过 Linux 原生 API 我们可以如何对接硬件。

在此之前，需要明确一件事情，即一个 PCIe 设备的必备条件:

根据PCIe规范（PCI Express Base Specification），所有合规的PCIe设备必须包含以下要素：

1. PCI 配置空间（包括标准的64字节Header + 扩展空间）
2. 至少一个BAR（用于映射设备寄存器或内存区域）
3. PCIe Capability 结构（标识其为 PCIe 设备而非传统 PCI）

如果设备完全没有 BAR 空间，它甚至无法通过 PCIe 枚举阶段的配置，操作系统会直接将其视为不完整设备而忽略。

也就是说，如果硬件的功能比较简单，可能只利用 PCIe 规范的内容就可以完成了，

不过如果硬件的功能相对复杂，PCIe 规范的内容就不足以支撑我们的需求了，这时候就需要硬件在设计时增加额外的配置寄存器，驱动程序直接对这些寄存器进行操作从而配置更加复杂的硬件功能(不过本质都是寄存器)，这两种方式的对比如下图所示。

了解了与硬件交互的两种模式后，还需要明确一下驱动程序应该使用哪些内核 API 才能达到访问这些寄存器的目的。

1. PCIe设备基础配置

2. BAR空间管理

3. MMIO寄存器操作

4. DMA控制

5. 中断处理

IO 设备

IO 设备的基本形态就是一些寄存器(以及一些 protocol，说明在寄存器接收到某些值时要做出何种处理） + 控制器，从而能够与 CPU 交互数据，通过 mmap 的方式映射到内存空间中，CPU 可以对这些寄存器的值进行修改

实际只直接连接了总线一个设备(总线也是一个设备，CPU 仅连接这一个设备，其他设备连接在总线上），其他设备被总线虚拟化，并且挂载在总线上，形成一个树状分层结构，分层是逐层虚拟化的结果

文件系统

Linux 系统中的 /proc 目录是一个虚拟文件系统。它提供了内核和系统进程的动态信息，实际上并不占用硬盘空间，而是直接从内存中生成，反映当前内核和进程的实时状态。

1. 进程信息

每个正在运行的进程都有一个对应的目录，名称就是进程的 PID（进程号），如 /proc/1/。

这些进程目录下包含进程的详细信息:

• cmdline：进程的启动命令
• status：进程的状态信息，包括 PID、父进程 PID、内存使用情况等
• fd/：进程打开的文件描述符
• maps：进程的内存映射情况

2. 系统信息文件

• /proc/cpuinfo：CPU 的信息，比如型号、核心数、频率等。
• /proc/meminfo：内存的使用情况，比如总内存、空闲内存等。
• /proc/uptime：系统已运行的时间。
• /proc/version：Linux 内核的版本信息。
• /proc/loadavg：系统的平均负载情况。

3. 硬件设备相关信息

• /proc/interrupts：显示系统的中断请求（IRQ）使用情况。
• /proc/ioports：显示分配给硬件设备的 I/O 端口信息。
• /proc/partitions：列出系统中的分区信息。

4. 内核参数

• /proc/sys/：内核参数配置的目录。可以通过这个目录读取或写入一些内核参数来调整系统行为。比如 /proc/sys/net/ipv4/ip_forward 控制 IP 转发功能。

驱动程序

驱动程序所做的就是对设备寄存器的一层封装，简单来理解，用户期望对设备进行的操作最终到硬件上都将转换为对于设备寄存器的访问，硬件电路是具有一些基础性的功能的，当期望使用这些功能时，只需要向一些寄存器中写入数据即可，较复杂的功能也不过是这些简单功能的叠加，所以驱动程序可以将一些复杂动作所对应的寄存器操作序列封装为接口，上层看到的只是这些接口，并不关心想要实现这些功能时到底需要向哪些寄存器写入哪些值。例如 Capric 卡上 DMA 读功能的实现:

1. 填写 RD_DMA_ADR 寄存器， 注意此处填写的是 PCI 总线域的地址。
2. 填写 RD_DMA_SIZE 寄存器， 以字节为单位。
3. 填写 DCSR2 寄存器的 mrd_start 位， 启动 DMA 读。
4. 等待 DMA 读完成中断产生后， 结束 DMA 读。

上述过程中，前两点的数据填充并不难理解，第三点通过向寄存器写入值开启 DMA 过程更给人启发。

理解驱动程序，从最上层考虑，以打印机为例，使用者执行了一个动作，这个动作触发了系统调用，系统调用又转换到驱动程序，驱动程序进行翻译工作，将这个动作信号翻译为设备所能理解的数据。

所以比较令人困惑的是，这种翻译到底是将什么翻译为了什么？

目前来理解，驱动程序在实现时，核心操作就是对于寄存器的读写，无论是数据寄存器还是配置寄存器。

驱动程序就是一段内核代码，所以并不一定有真实的物理设备，它只对应于一种翻译逻辑。

设备驱动程序的职责是把系统调用 “翻译” 成与设备能听懂的数据(在 jyy 所提供的实例中，设备实际是两个虚拟设备）我们可以通过实现 file_operations 中相应的操作，从而模拟一个设备。

因为 “everything is file”，所以设备本身也是 file，所以驱动程序代码完成的就是对于文件的读写操作，只不过需要写入的数据是需要设备所能够理解的。

Linux 中对于 /dev/null 的实现，这就能理解为什么向这个字符写入数据时，数据总是能够被吞噬掉

Linux 内核中的驱动程序

操作系统内核的标准系统调用可以处理简单的文件和设备操作，但是无法满足对于设备更加复杂的控制功能，ioctl 可以轻松扩展系统与设备的交互能力

通过 ioctl 机制，可以在用户态使用提前定义好的命令码与设备驱动程序通信，执行特定于设备的控制或配置功能，从而补充操作系统内核的标准系统调用不能满足的设备操作需求。

1. 命令码的定义： 驱动程序开发者需要定义一组命令码，每个命令码对应一个特定的设备操作。这些命令码通常是通过宏定义的，使用了位操作来区分命令的类型和数据方向（输入或输出）。

1
2
3

#define MY_IOCTL_MAGIC 'x'
#define MY_IOCTL_CMD1 _IOR(MY_IOCTL_MAGIC, 1, int)
#define MY_IOCTL_CMD2 _IOW(MY_IOCTL_MAGIC, 2, struct my_struct)

2. 驱动程序的实现： 在设备驱动程序中，需要实现对这些命令码的处理逻辑。通常，驱动会通过 file_operations 结构体的 unlocked_ioctl 或 compat_ioctl 成员函数，来处理这些 ioctl 请求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

long my_device_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
    switch (cmd) {
        case MY_IOCTL_CMD1:
            // 处理命令 1
            break;
        case MY_IOCTL_CMD2:
            // 处理命令 2
            break;
        default:
            return -EINVAL;  // 无效命令码
    }
    return 0;
}

3. 用户态调用 ioctl： 用户态程序可以通过调用 ioctl()，并传入文件描述符、命令码及可选参数来与驱动程序通信。驱动会根据传入的命令码，执行相应的操作。

1
2
3

int fd = open("/dev/mydevice", O_RDWR);
int data;
ioctl(fd, MY_IOCTL_CMD1, &data);  // 执行命令 1，读取数据

驱动程序无论是直接编译到内核还是以模块的方式挂载到内核上，本质上驱动程序的执行都应该是属于内核态的，那么上层应用程序如果希望利用上驱动程序与设备进行交互，那就还是需要通过系统调用，借助操作系统来对设备进行操作。那么 sdk 完成的是否就是对于这个请求系统调用过程的封装？

从 jyy 老师的这个课程中理解到的驱动程序，它通过自定义实现 launcher_read 和 launcher_write，并且在 file_operations 中指定这两个函数，从而规定了设备在面对读操作和写操作时的应对方法，所以驱动程序确实就是将设备作为文件来看待，规定文件读写操作时的操作方法。

驱动 操作系统 层次关系

硬件抽象层（HAL），操作系统对具体的硬件进行抽象，向上层软件提供 API。在 PCI 的情况下，内核代码中的 PCI 子系统即相当于这一抽象层。

PCI 本身具有一定标准，PCI 子系统只需要遵循这个标准，就可以和设备进行一些例如识别设备在内的一些基础性的交互。

如何理解“驱动程序可以提供更高级别的抽象，让系统更好地利用设备的功能“这句话？

首先这确实是驱动程序的功能，但是该如何理解这种”抽象“。举一个简单的例子，向磁盘和网卡写入数据，两种设备的硬件组成（寄存器）一定是不同的，那么写操作也不相同，通过 PCI 子系统的 API 也是可以完成的，但是要复杂很多，驱动程序可以抽象出一个通用的 write() 接口 API，从而简化这种操作。

第三方库

并不类似于 C 语言能够使用很多第三方库，在编写驱动程序时，只能使用一些内核代码中提供的函数，例如 printk()

printk() 支持的消息等级：

kernel

dmesg 可以显示内核日志信息中（实际是指的是内核环形缓冲区）

开发模式

驱动程序的开发模式是事件驱动的编程，例如

• 模块初始化函数所做的类似于它自身在说：“我在这里，这是我能做的”

• 模块退出函数所做的类似于它自身在说：“我不再在那里了，不要要求我做任何事了”

模块开发并不能链接其他库，它所能使用的只能是内核代码中的内容（有唯一的一个例外是<stdarg.h> ）

用户态和内核态有独立的内存地址空间

内核代码的执行是并发的，因此它的设计必须能够可重入（能够同时在多个上下文运行）

相关命令

• insmod：挂载一个模块

• rmmod：去除一个模块

• lsmod: 获取当前加载的模块 等价于读取 /proc/modules 或 /sys/module

描述性定义

• MODULE_AUTHOR: 声明谁编写了模块

• MODULE_DESCRIPION: 模块具体描述

• MODULE_VERSION: 代码修订版本号

• MODULE_ALIAS: 模块别名

• MODULE_DEVICE_TABLE: 模块支持的设备列表

传递参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

static char *whom = "admin";
static int times = 1;
module_param(whom, charp, S_IRUGO);
module_param(times, int, S_IRUGO);

static int hello_init(void) {
        // KERN_ALERT: 消息优先级
        printk(KERN_ALERT "hello %s x %d\n", whom, times);
        return 0;
}

概念辨析

1. 操作系统 API
2. 库函数
3. 系统调用

这部分可以补充一个“从文件读写了解这些概念”这样一个内容

目前了解到的内容：

内核代码中大概包含了两部分：

1. 系统调用（System Calls）: 名称均以 sys_ 开头, 用户空间应用与内核通信的唯一标准接口
2. 内核函数（Kernel Functions）: 内部调用接口，不能直接被用户空间应用访问

chatgpt 给出的流程，但是我觉得还是有些问题的，更常见的场景是用户空间的程序通过 glibc（GNU C Library）或者其他标准库中的包装函数，后面通过中断号找到对应的系统调用函数

1. 用户空间应用通过标准库调用系统调用接口（如 open()）。
2. 系统调用通过特定的硬件指令（如 syscall 或 int 0x80）陷入内核空间。
3. 内核根据系统调用号，定位到相应的 sys_* 函数（如 sys_open()）。
4. sys_* 函数调用一系列内核内部函数来完成任务，最后将结果返回给用户空间。

ioctl

允许用户态程序通过文件描述符向设备驱动程序发送控制命令并接收返回的结果。

典型的用法是传递控制命令和数据缓冲区。

设备节点作为应用程序和驱动程序（操作系统）沟通的桥梁，用来使双方传输数据

驱动程序如何维护 ioctl 所使用的标识和对应的操作之间的映射关系？

1. file_operations 结构体的 unlocked_ioctl 成员指向具体的 ioctl 处理函数，例如 pGbl_DriverObject->DispatchTable.unlocked_ioctl = Dispatch_IoControl;

2. 处理函数根据 cmd 的值（所谓的 ioctl 使用的标识）执行不同的处理逻辑，例如

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

switch (cmd) {
	case PLX_IOCTL_PCI_DEVICE_FIND:
		DebugPrintf_Cont(("PLX_IOCTL_PCI_DEVICE_FIND\n"));
		
		pIoBuffer->ReturnCode =
			PlxDeviceFind(
				pdx,
				&(pIoBuffer->Key),
				PLX_CAST_64_TO_16_PTR( &(pIoBuffer->value[0]) )
			);

		break;

	case xxx:
}

检查系统中驱动情况

find /lib/modules/$(uname -r) -type f -name "*plx*"

同时结合 modinfo 命令

不过似乎上述位置能够找到的 module，是经过了 modprobe 处理了依赖关系后的，insmod 不会自动处理依赖关系或将模块安装到此路径下。

PCI PCIe

检查 PCIe 设备及查看驱动

1
2
3
4
5

# 查看全部 PCIe 设备的详细信息
lspci -v

# 单独查看设备的驱动情况
lspci -k -s 前面那串数字

lsmod 查看已经加载到内核中的模块

PCI: 局部总线（连接外部设备），系统总线（CPU 连接 Cache 和 主存）的延伸。

PCI: 并行总线；PCIe：高速串行总线

处理器需要通过 HOST 主桥才能访问 PCI 设备， 而 PCI 设备需要通过 HOST 主桥才能访问主存储器

主板上的 PCIe 有接口和通道两种模式

1. 接口：

PCIe 设备：显卡，固态，无线网卡，有线网卡，声卡，视频采集卡，PCIe 转接其他接口（高带宽需求的外部设备）

2. 通道

m2 固态硬盘接口外形是 m2，但是实际数据传输依赖的是 PCIe

雷电 3 接口也是利用了 PCIe 通道来达到高带宽

带宽分配（按照长度分配）：PCIe x1，x2，x4，x8，x16（x16 的带宽是 x8 的 2倍），可以将 x16 的设备插在较短的 PCIe 槽中运行，但是没办法发挥全部性能，也可以将较短的设备插在较长的槽中运行，但是会浪费带宽（满血，残血指的是设备长度长于插槽长度的情况）

PCI 驱动程序加载流程

1. module_init(): 更高层次的，专门用于模块初始化。指定模块加载时的初始化函数，它的作用范围是整个模块，而不仅限于某种特定的硬件。

2. pci_register_driver(): 专门用于向内核注册 PCI 驱动程序的，它只能在 PCI 驱动程序中使用，并且其作用是告诉内核该驱动能够处理哪些 PCI 设备。(USB 设备的注册函数是 usb_register_driver()）¹

因为注册驱动程序的本质就是让操作系统内核了解到该用哪些函数来对应中断信号，因此这些特定于设备的驱动注册函数一定是操作系统标准库提供的(include/linux/pci.h, 内核中的 PCI 子系统 API)。

模块加载 -> 执行 module_init 宏中指定的初始化函数 → 在该函数中调用 pci_register_driver 将驱动程序注册到内核。

结构

Host 端 CPU 芯片或主板的北桥上有一个 Root Complex (RC) 芯片(可能已经集成到 CPU 上了）, 负责与设备端的 PCIe 端点（Endpoints）通信。

Device 端有一个Endpoint (EP)，通过 PCIe 与 Root Complex 通信，充当这个 EP 的可能就是 PLX 芯片了，不过类似 RC，可能已经集成到加速卡芯片内部了。

这就涉及到了 PLX 的作用：

1. 位于 Host 端-PCIe 扩展桥接，用于扩展 PCIe 通道数量，以支持更多的外部设备。
2. 位于 Device 端-板卡端的 DMA 控制，用于管理板卡与主机之间的数据传输，尤其是 DMA（Direct Memory Access） 操作。

南桥芯片组

PCIe 高频总线，主板做多层（多层 PCB）提供支持

PCIe 直接连接在 CPU 的PCIe 控制器上，从而做到超低延迟：

²

因为外围数量众多，不可能全部都直接同 CPU 进行交互，因此存在一个南桥芯片组，一些非极其重要的设备先和南桥交互，由南桥将数据或请求汇总好后再统一交由 CPU 处理(下图中红色表示和 CPU 直连的设备）

关于带宽的分配问题：

有这样一个问题：如果在上述 Intel Z390 平台主板上同时插入了显卡( PCIe x16 )和 m2 固态硬盘( PCIe x4 )，那么是否意味着两个设备是共享或者说抢占（注意左上角直连 PCIe 的几种选择之间是或的关系，即同时最大只有 x16 的带宽）和 CPU 直连的那 x16 的 PCIe 通道？

答案是不会，因为 m2 固态用的是和南桥连接的非直连 PCIe 总线上的

而在 AMD Ryzen 平台，提供了 20 条直连 PCIe 通道，其中 x16 可以分配给显卡，另外 x4 则可以分配给 m2，此时相当于二者共享这 20 条通道。

而南桥芯片组和 CPU 的连接是通过 PCIe 3.0x4，在 Intel 下，将其称之为 DMI 3.0，AMD 则直接标注了 PCIe。

PCI 设备

在为 PCI 设备安装驱动之前，在系统的 /sys/bus/pci/devices/ 路径下就能看到设备对应的文件夹，这是如何做到的？

本质原因在于硬件和软件均遵循了预先定义好的 PCI 标准，硬件方面，每个设备都有一个标准的 PCI 配置空间（一些寄存器），其中包含 Vendor ID 和 Device ID 等关键信息；软件方面，Linux 内核包含一个 PCI 子系统，那么 PCI 子系统可以通过总线读取这些寄存器中的值，从而即使在没有驱动程序的支持下也依然能够获取到设备的基础信息。

PCI 配置空间

PCI 规范决定了，在 PCI 设备的配置空间中，一个字(word)的长度固定为 16 位，无论操作系统是 32 位还是 64 位。

PLX Driver

Linux kernel 提供了对于 pci device 的支持的，内核代码中包含一些 PCI 设备结构体以及一些注册函数，例如

driver information struct:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

struct pci_driver {
	const char		*name;
	const struct pci_device_id *id_table;	/* Must be non-NULL for probe to be called */
	int  (*probe)(struct pci_dev *dev, const struct pci_device_id *id);	/* New device inserted */
	void (*remove)(struct pci_dev *dev);	/* Device removed (NULL if not a hot-plug capable driver) */
	int  (*suspend)(struct pci_dev *dev, pm_message_t state);	/* Device suspended */
	int  (*resume)(struct pci_dev *dev);	/* Device woken up */
	void (*shutdown)(struct pci_dev *dev);
	int  (*sriov_configure)(struct pci_dev *dev, int num_vfs); /* On PF */
	int  (*sriov_set_msix_vec_count)(struct pci_dev *vf, int msix_vec_count); /* On PF */
	u32  (*sriov_get_vf_total_msix)(struct pci_dev *pf);
	const struct pci_error_handlers *err_handler;
	const struct attribute_group **groups;
	const struct attribute_group **dev_groups;
	struct device_driver	driver;
	struct pci_dynids	dynids;
	bool driver_managed_dma;
};

register function:

1
2

#define pci_register_driver(driver)		\
	__pci_register_driver(driver, THIS_MODULE, KBUILD_MODNAME)

The above content is used to mount the driver to the kernel, mount 操作完成的只是让内核能够看到挂载的驱动模块的一些基本信息，但是驱动模块具体负责做什么在上面的内容中并没有说明，所以接下来还需要对这些内容进行说明。

定义驱动程序的行为和资源管理方式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Main driver object
typedef struct _DRIVER_OBJECT
{
    struct _DEVICE_OBJECT  *DeviceObject;     // Pointer to first device in list
    spinlock_t              Lock_DeviceList;  // Spinlock for device list
    dev_t                   devno;
    int                     MajorID;          // The OS-assigned driver Major ID
    U8                      DeviceCount;      // Number of devices in list
    U8                      bPciDriverReg;    // Flag whether the driver was registered as PCI

    unsigned  long          bufPhyMemMode;//   0 -
///////////////////////////////////// bufPhyMemMode == PHY_MEM_MODE_CONST
	PLX_PHYS_MEM_OBJECT	   *bufDMA;	  // Contiguous memory for application
    struct list_head        bufFree;
	spinlock_t              bufFreeLock;
	int                     bufNum;
////////////////////////////////////  bufPhyMemMode == PHY_MEM_MODE_RTREE
	spinlock_t              DMALock;
	DmaMem_t                DMAMem;
////////////////////////////////////  bufPhyMemMode == PHY_MEM_MODE_RPOOL
	struct mem_pool        *reserve_mem_pool;
/////////////////////////////////
    struct file_operations  DispatchTable;    // Driver dispatch table
} DRIVER_OBJECT;

从 file_operations 进一步理解 Linux “everything is a file” 的理念。

file_operations 为内核代码中提供的结构体，驱动程序所做的事情即为该结构体中所预留的函数指针指定一个驱动程序所实现的函数，例如：pGbl_DriverObject->DispatchTable.read = Dispatch_read;, 而 Dispatch_read 是驱动程序所实现的一个函数。当驱动挂载至内核后，我们对于设备的读请求就等价于对于读文件。

At the same time, we can also know that 设备驱动的源代码包含的除了一些驱动注册的代码之外，最主要的就是完成 file_operations 中所包含的函数，以此给上层提供文件模式的设备访问控制方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

struct file_operations {
	struct module *owner;
	fop_flags_t fop_flags;
	loff_t (*llseek) (struct file *, loff_t, int);
	ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
	ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
	ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
	ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
	int (*iopoll)(struct kiocb *kiocb, struct io_comp_batch *,
			unsigned int flags);
	int (*iterate_shared) (struct file *, struct dir_context *);
	__poll_t (*poll) (struct file *, struct poll_table_struct *);
	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
	int (*mmap) (struct file *, struct vm_area_struct *);
	int (*open) (struct inode *, struct file *);
	int (*flush) (struct file *, fl_owner_t id);
	int (*release) (struct inode *, struct file *);
	int (*fsync) (struct file *, loff_t, loff_t, int datasync);
	int (*fasync) (int, struct file *, int);
	int (*lock) (struct file *, int, struct file_lock *);
	unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
	int (*check_flags)(int);
	int (*flock) (struct file *, int, struct file_lock *);
	ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
	ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
	void (*splice_eof)(struct file *file);
	int (*setlease)(struct file *, int, struct file_lease **, void **);
	long (*fallocate)(struct file *file, int mode, loff_t offset,
			  loff_t len);
	void (*show_fdinfo)(struct seq_file *m, struct file *f);
#ifndef CONFIG_MMU
	unsigned (*mmap_capabilities)(struct file *);
#endif
	ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
			loff_t, size_t, unsigned int);
	loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
				   struct file *file_out, loff_t pos_out,
				   loff_t len, unsigned int remap_flags);
	int (*fadvise)(struct file *, loff_t, loff_t, int);
	int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
	int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
				unsigned int poll_flags);
} __randomize_layout;