技术

学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go 内存管理 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes垂直扩缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Prometheus 学习 容器日志采集 Kubernetes 控制器模型 Kubernetes监控 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

生命周期管理 openkruise学习 可观察性 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Kubernetes webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 kubebuilder 及controller-runtime学习 pv与pvc实现 csi学习 client-go学习 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 《推荐系统36式》笔记 资源调度泛谈 系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 《聊聊架构》 书评的笔记 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

招聘Java

招聘Java开发

标签


Linux IO学习

2017年04月16日

简介

​网络 IO 演变发展过程和模型介绍

io设备

磁盘(和内存)是一个可寻址的大数组(内存寻址:段 ==> 页 => 字节,磁盘寻址 磁盘 ==> xx ==> 字节),而os和应用都无法直接访问这个大数组(强调一下,即便是os,也是通过文件系统,即/xx/xx的方式来访问文件的。这也是为什么load os的时候,有一个初始化文件系统的过程)。文件系统则是更高层抽象,文件系统定义了文件名、路径、文件、文件属性等抽象,文件系统决定这些抽象数据保存在哪些块中。

  设备
面向流 tty、socket
面向块 磁盘

当我们需要进行文件操作的时候,5个API函数是必不可少的:Create,Open,Close,Write和Read函数实现了对文件的所有操作。PS:不要觉得close方法没用,但一个文件io都会占用一个fd句柄,close便用于释放它们。

阻塞非阻塞

我们从代码上理解下阻塞和非阻塞的含义

ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);

为socket设置nonblocking

// 设置一个文件描述符为nonblock
int set_nonblocking(int fd){
    int flags;
    if ((flags = fcntl(fd, F_GETFL, 0)) == -1)
        flags = 0;
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

异步网络模型

浅谈TCP/IP网络编程中socket的行为

阻塞io

非阻塞io

Non-blocking I/O 的特点是用户进程需要不断的主动询问 kernel 数据好了没有。非阻塞 IO 解决了阻塞 IO每个连接一个线程处理的问题,所以其最大的优点就是 一个线程可以处理多个连接,这也是其非阻塞决定的。但这种模式,也有一个问题,就是需要用户多次发起系统调用。频繁的系统调用是比较消耗系统资源的。

IO事件通知机制——IO复用,I/O 多路复用需要使用特定的系统调用,比如select/poll/epoll 等。可以一次找到所有缓冲区或连接状态发生变化的TCP连接。

​网络 IO 演变发展过程和模型介绍很多人都说,IO 多路复用是用一个线程来管理多个网络连接,但本人不太认可,因为在非阻塞 IO 时,就已经可以实现一个线程处理多个网络连接了,这个是由于其非阻塞而决定的。作者观点,多路复用主要复用的是通过有限次的系统调用来实现管理多个网络连接

IO事件通知机制——SIGIO

同步异步

数据的传递需要两个阶段,只要任何一个阶段会阻塞用户请求,都将其称为同步 IO,两个阶段都不阻塞,则称为异步 IO。在目前所有的操作系统中,linux 中的 epoll、mac 的 kqueue 都属于同步 IO,因为其在第二阶段(数据从内核态到用户态)都会发生拷贝阻塞。而只有 windows 中的 IOCP 才真正属于异步 IO,即 AIO。

各个io模型对比

从bio 到nio

多种I/O模型及其对socket效率的改进

对于一次IO访问(以read举例),数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说,当一个read操作发生时,它会经历两个阶段:

  1. 等待数据准备 (Waiting for the data to be ready)
  2. 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

也就是说,不管是阻塞、非阻塞、多路复用io,第一阶段都是用户进程主动去发现socket send/receive buffer是否ready,区别只是 用户态轮询还是内核态轮询(比如select/poll)和一次轮询几个fd的问题,第二阶段都是要阻塞。而异步io则是内核主动向用户进程发起通知的,第一和第二个阶段都不会阻塞。 PS: 这是这个博客最重要的一句话。

从bio 到 nio 这个小进步,便使得redis 有底气使用单线程来扛高负载,Redis 学习

从nio 到aio

异步I/O是由内核接管应用层对fd的I/O操作,像 Windows 的 IOCP 这一类的异步 I/O,只需要在调用 WSARecv 或 WSASend 方法读写数据的时候把用户空间的内存 buffer 提交给 kernel,kernel 负责数据在用户空间和内核空间拷贝,完成之后就会通知用户进程,整个过程不需要用户进程参与

netty 通过多加一层,netty 引擎层持有fd 引用(也就是socket channel),变相的将多路复用io封装为异步效果。参见异步编程

陈皓在《左耳听风》中提到:异步io模型的发展技术是:select -> poll -> epoll -> aio -> libevent -> libuv。其演化思想参见: Understanding Reactor Pattern: Thread-Based and Event-Driven

io 与 上层应用/rpc整合

深入剖析通信层和 RPC 调用的异步化(上)

  同步阻塞 I/O(BIO) 非阻塞 I/O(NIO) 异步 I/O(AIO)
客户端个数:I/O 线程 1:1 M:1(1 个 I/O 线程处理多个客户端连接) M:0(不需要用户启动额外的 I/O 线程,被动回调)
I/O 类型(阻塞) 阻塞 I/O 非阻塞 I/O 非阻塞 I/O
I/O 类型(同步) 同步 I/O 同步 I/O(I/O 多路复用) 异步 I/O
API 使用难度 简单 非常复杂 复杂
调试难度 简单 复杂 复杂
可靠性 非常差
吞吐量

从中笔者解决了一直以来对NIO和AIO的一个疑惑:非阻塞io + rpc层异步化 也可以给上层业务层 提供 异步的感觉,但其毕竟比 AIO 多一个IO线程。

源码分析

Go netpoller 网络模型之源码全面解析

IO 多路复用中,select()/poll()/epoll_wait()这几个函数对应第一阶段;read()/recvfrom()对应第二阶段

select

#include <sys/select.h>
/* According to earlier standards */
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
// 和 select 紧密结合的四个宏:
void FD_CLR(int fd, fd_set *set);
int FD_ISSET(int fd, fd_set *set);
void FD_SET(int fd, fd_set *set);
void FD_ZERO(fd_set *set);

select 函数监视的文件描述符分 3 类,分别是 writefds、readfds、和 exceptfds。调用后 select 函数会阻塞,直到有描述副就绪(有数据 可读、可写、或者有 except),或者超时(timeout 指定等待时间,如果立即返回设为 null 即可),函数返回。当 select 函数返回后,可以 通过遍历 fdset,来找到就绪的描述符。

  1. 理解 select 的关键在于理解 fd_set,为说明方便,取 fd_set 长度为 1 字节,fd_set 中的每一 bit 可以对应一个文件描述符 fd,则 1 字节长的 fd_set 最大可以对应 8 个 fd。可监控的文件描述符个数取决于 sizeof(fd_set) 的值。假设服务器上 sizeof(fd_set)=512,每 bit 表示一个文件描述符,则服务器上支持的最大文件描述符是 512*8=4096。
  2. 每次调用 select,都需要把 fd 集合从用户态拷贝到内核态,这个开销在 fd 很多时会很大
  3. 每次 kernel 都需要线性扫描整个 fd_set,所以随着监控的描述符 fd 数量增长,其 I/O 性能会线性下降

IO 多路复用第一版:IO 多路复用,主要在于复用。通过 select()或者 poll()将多个 socket fds 批量通过系统调用传递给内核,由内核进行循环遍历判断哪些 fd 上数据就绪了,然后将就绪的 readyfds 返回给用户。再由用户进行挨个遍历就绪好的 fd,读取或者写入数据。所以通过 IO 多路复用+非阻塞 IO,一方面降低了系统调用次数,另一方面可以用极少的线程来处理多个网络连接。 但返回的活跃连接 == select(全部待监控的连接)同时引入了新的问题:用户需要每次将海量的 socket fds 集合从用户态传递到内核态,让内核态去检测哪些网络连接数据就绪了,再把就绪的fd从内核态拷贝到用户态。这个地方开销挺大。

epoll

IO 多路复用第二版:其实思路也挺简单,既然需要拷贝,那就想办法,不拷贝。既然不拷贝,那就在内核开辟一段区域来存放管理的 fd咯

epoll内核源码分析epoll 接口

// 创建一个epoll struct,当创建好epoll句柄后,并把它关联到当前进程的已打开文件列表中。
int epoll_create(int size);
// epoll的事件注册函数。告诉内核 需要监听 fd 的哪些 epoll_event
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
// epoll_wait 则是阻塞监听 epoll 实例上所有的 file descriptor 的 I/O 事件。参数events用来从内核得到事件的集合
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

struct eventpoll{
    file *file;
    rb_root rbr;            // 红黑树
    list_head rdlist;       // 就绪链表,当有的连接就绪的时候,内核会把就绪的连接放到 rdllist 链表里。这样应用进程只需要判断链表就能找出就绪进程,而不用去遍历整棵树。
    wait_queue_head_t wq    // 等待队列,软中断数据就绪的时候会通过 wq 来找到阻塞在 epoll 对象上的用户进程。
}

深入揭秘 epoll 是如何实现 IO 多路复用的

  1. epoll 采用红黑树来存储所有监听的 fd,而红黑树本身插入和删除性能比较稳定,时间复杂度 O(logN)。通过 epoll_ctl 函数添加进来的 fd 都会被放在红黑树的某个节点内
  2. 当把 fd 添加进来的时候时候会 将ep_poll_callback 注册到socket 的等待队列项中(回到函数是 sk_data_ready)。数据包到来时 tcp_v4_rcv ==> tcp_v4_do_rcv ==> tcp_rcv_established ==> tcp_queue_rcv 将接收数据放到 socket 的接收队列上,接着再调用 sk_data_ready(一个函数指针) ==> ep_poll_callback。ep_poll_callback 把这个 fd 添加到 rdllist 双向链表(就绪链表)中。
  3. epoll_wait 实际上就是去检查 rdllist 双向链表中是否有就绪的 fd,当 rdllist 为空(无就绪 fd)时挂起当前进程,加入到wq中,直到 rdllist 非空时进程才被唤醒并返回。是的,当没有 IO 事件的时候, epoll 也是会阻塞掉当前进程。

static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
           int maxevents, long timeout){
    if (timeout > 0) {
        ...
    } else if (timeout == 0) {
        ...
        goto check_events; // 如果timeout等于0,函数不阻塞,直接返回
    }
fetch_events:
    if (!ep_events_available(ep))
        ep_busy_loop(ep, timed_out);
    spin_lock_irqsave(&ep->lock, flags);
    /*
    当没有事件产生时((!ep_events_available(ep))为true),调用__add_wait_queue_exclusive函数将当前进程加入到ep->wq等待队列里面,然后在一个无限for循环里面,首先调用set_current_state(TASK_INTERRUPTIBLE),将当前进程设置为可中断的睡眠状态,然后当前进程就让出cpu,进入睡眠,直到有其他进程调用wake_up或者有中断信号进来唤醒本进程,它才会去执行接下来的代码。
    */
    if (!ep_events_available(ep)) {
        ep_reset_busy_poll_napi_id(ep);
        init_waitqueue_entry(&wait, current);
        __add_wait_queue_exclusive(&ep->wq, &wait);
        for (;;) {
            set_current_state(TASK_INTERRUPTIBLE);
            /*
                如果进程被唤醒后,首先检查是否有事件产生,或者是否出现超时还是被其他信号唤醒的。如果出现这些情况,就跳出循环,将当前进程从ep->wp的等待队列里面移除,并且将当前进程设置为TASK_RUNNING就绪状态。
            */
            if (ep_events_available(ep) || timed_out)
                break;
            if (signal_pending(current)) {
                res = -EINTR;
                break;
            }
            spin_unlock_irqrestore(&ep->lock, flags);
            if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
                timed_out = 1;
            spin_lock_irqsave(&ep->lock, flags);
        }
        __remove_wait_queue(&ep->wq, &wait);
        __set_current_state(TASK_RUNNING);
    }
check_events:
    //  如果真的有事件产生,就调用ep_send_events函数,将events事件转移到用户空间里面。
    eavail = ep_events_available(ep);
    spin_unlock_irqrestore(&ep->lock, flags);
    if (!res && eavail &&
        !(res = ep_send_events(ep, events, maxevents)) && !timed_out)
        goto fetch_events;
    return res;
}

进程什么时候被唤醒呢?在调用epoll_ctl为目标文件注册监听项时,对目标文件的监听项注册一个ep_ptable_queue_proc回调函数,ep_ptable_queue_proc回调函数将进程添加到目标文件的wakeup链表里面,并且注册ep_poll_callbak回调,当目标文件产生事件时,ep_poll_callbak回调就去唤醒等待队列里面的进程。

其它

read 系统调用剖析“Linux 系统调用(SCI,system call interface)的实现机制实际上是一个多路汇聚以及分解的过程,该汇聚点就是 0x80 中断这个入口点(X86 系统结构)。也就是说,所有系统调用都从用户空间中汇聚到 0x80 中断点,同时保存具体的系统调用号。当 0x80 中断处理程序运行时,将根据系统调用号对不同的系统调用分别处理(调用不同的内核函数处理)。”

存储之道 - 51CTO技术博客 中的《一个IO的传奇一生》

Linux IO模式及 select、poll、epoll详解

俱往矣——UIO

Linux设计初衷是以通用性为目的的,但随着Linux在服务器市场的广泛应用,其原有的网络数据包处理方式已很难跟上人们对高性能网络数据处理能力的诉求。在这种背景下DPDK应运而生,其利用UIO技术,在Driver层直接将数据包导入到用户态进程,绕过了Linux协议栈,接下来由用户进程完成所有后续处理,再通过Driver将数据发送出去。原有内核态与用户态之间的内存拷贝采用mmap将用户内存映射到内核,如此就规避了内存拷贝、上下文切换、系统调用等问题,然后再利用大页内存、CPU亲和性、无锁队列、基于轮询的驱动模式、多核调度充分压榨机器性能,从而实现高效率的数据包处理。

缓冲区

缓冲区的表现形式:

  1. 对于网络:socket有一个send buffer和receive buffer;
  2. 对于磁盘:内存会有一个专门的区域划分为缓冲区,由操作系统管理

浅谈TCP/IP网络编程中socket的行为,无论是磁盘io还是网络io,应用程序乃至r/w系统调用都不负责数据实际的读写(接收/发送)。对于每个socket,拥有自己的send buffer和receive buffer。以write操作为例,write成功返回,只是buf中的数据被复制到了kernel中的TCP发送缓冲区。至于数据什么时候被发往网络,什么时候被对方主机接收,什么时候被对方进程读取,系统调用层面不会给予任何保证和通知。已经发送到网络的数据依然需要暂存在send buffer中,只有收到对方的ack后,kernel才从buffer中清除这一部分数据,为后续发送数据腾出空间。这些控制皆发生在TCP/IP栈中,对应用程序是透明的,应用程序继续发送数据,最终导致send buffer填满,write调用阻塞。

这就跟我潜意识的认知,稍稍有点不同。我以前的认为是,一个write操作,数据从发起,到调用网卡驱动发数据,都是一起干完的。

缓冲区既可以处理各部件速度不一致的矛盾,也可以作为各个子系统的边界存在。

linux0.11内核文件读取的过程

  1. 应用程序调用系统调用read(包含文件路径等参数),进入内核态。
  2. 内核根据文件路径找到对应的设备号和磁盘数据块。(磁盘的索引块事先会被加载到内存)
  3. 先申请一个缓冲区块,将磁盘数据块挂到缓冲区块上(如果该缓冲区块已存在,就算了),进程挂起(直到缓冲块数据到位)。
  4. 将缓冲区块挂接到一个请求项上(struct request)。(该struct描述了请求细节:将某个设备的某数据块读到内存的某个缓冲区块上)
  5. 将请求项挂到该设备的请求队列上
  6. 该设备处理这个请求项时,根据设备号和块设备struct(预先初始化过),找到该设备的请求项处理函数
  7. 请求项处理函数取出该设备请求项队列的队首请求项,根据请求项的内容(操作什么设备,读还是写操作,操作那个部分,此处以读操作为例)给设备下达指令(将相应数据发送到指定端口),并将读盘服务程序与硬盘中断操作程序挂接。
  8. 硬盘读取完毕后发生中断,硬盘中断程序除进行常规操作(将数据读出到相应寄存器端口)外,调用先前挂接到这里的读盘服务程序
  9. 读盘服务程序将硬盘放在数据寄存器端口的数据复制到请求项指定的缓冲块中,并根据数据是否读取完毕(根据请求项内容判断),决定是否停止读取。
  10. 如果读取完毕,唤醒因为缓冲块挂起的进程。否则,继续读取。

上述叙述主要涉及了内核态操作,并不完全妥当,但整体感觉是有了。缓冲区读取完毕后,内核随即把数据从内核空间的临时缓冲区拷贝到进程执行read()调用时指定的缓冲区。