探索

IA-32 体系结构中由三种模式和一种准操作结构： 实模式：与 8086 兼容的操作模式，有一些拓展。 保护模式：处理器的一种最基本的操作模式，在这种模式中，处理器的所有指令及体系结构中的所有特色都是可用的，并且能够达到最高性能。 系统管理模式，提供给操作系统的一种透明的管理机制，用于实现电源管理等特殊操作。 虚拟 8086 模式是一个准操作模式，允许处理器在保护模式中执行实模式的程序。 Intel 64 体系结构新增一种 IA-32e 操作模式包含两个子模式 兼容模式，在该模式下可以不加修改地运行大多数 IA-32 体系结构的程序 64 位模式，可以使用 64 位线性地址空间和一些新增加的特性。IA-32e 不再支持虚拟 8086 模式 处理器加电或者 Reset 后默认操作模式是实模式。 实模式和保护模式之间的转换由控制寄存器 CR0 中的 PE 位控制。 保护模式和 IA-32e 模式之间的转换由 IA32_EFER 寄存器中的 LME 和 CR0 中的 PE 位控制。 兼容模式和 64 位模式之间的转换由代码段寄存器 CS 和 L 位控制。 保护模式和虚拟 8086 模式之间的转换由标志寄存器 EFLAGS 中的 VM 位控制。 进入系统管理模式的唯一途径是 SMI 中断，在系统管理模式中执行指令 RSM 会将处理器切换回原来的操作模式。

Chromium 浏览器内核中，来自前端的内容如何在最终转换成为屏幕上的各个像素点，也就是浏览器内核渲染过程，这是一个复杂的工程上的一系列步骤。对于这些复杂的步骤我们需要把握的方面包括该过程每个阶段的设计思想、数据模型、数据模型的交互。深入而仔细地理解上述内容，有利与我们阅读庞大源码中始终保持清醒找准定位。下面我将基于我对 Life of a Pixel 的理解仔细来讨论这个过程。 Life of a Pixel 输入与输出 首先需要谈谈输入与输出，这一系列步骤的输入成为 Web Content。它由一系列现有协议所定义的一套描述 Web 内容的文本主要组成，当然也包括其他引用内容。现有的协议（我们常称为编程语言），通常是 HTML、CSS 与 JavaScript。这三者分别有定义了 Web 内容的结构内容、样式、逻辑。但这并非严格分工，在当下流行的前端设计思想（前后端分离）中 JavaScript 正在承担着越来越多的职责。JavaScript 本身也正在不断地变得独立，近年来逐渐跳出浏览器这个平台来独立发挥其作用（node.js、react-vr）。 另一方面，谈谈输出。如何绘制屏幕上的像素，涉及到计算机图形学方面的理论与工程。在传统上，我们可以认为计算机向屏幕输出内容经历了以下步骤。应用软件将其想要表达的图形内容转换成为对操作系统与图形相关的函数库的调用（OpenGL、Direct X 等），这些函数库通过操作系统中安装驱动程序及其他操作系统有关服务向硬件（GPU 等）传送数据与指令，并操纵硬件的计算核心与存储器（GPU 等）完成光栅化等步骤、最终将硬件（GPU 等）存储器中的最终内容转化为向屏幕输出的信号。在这方面，由函数库（OpenGL）所提供的 API 都是比较低级的。 举个例子，原来我也做过 OpenGL 相关的编程，虽然现代 OpenGL 提供一些模型与协议（如管线等）来简化工作，但是其提供的模型以及依照模型设计的 API 带有明显的硬件气息。对于 OpenGL 来说，调用者要精确输入预设的或者利用 GPU 程序计算出的数据其所绘制内容的在几何坐标系下的位置、颜色以及绘制顺序。 由输入输出来大致推断，浏览器的工作是按照先行前端协议（前端编程语言）及其附属多媒体、数据等方面的内容精确理解前端开发者对于 Web 页面的描述，并通过数据的层层流动与转换计算推断出图形函数库所需的各类信息。现行前端协议的复杂性与兼容性与鲁棒性要求使得这一步骤的实现十分复杂与庞大。而对于性能与稳定的要求更提升了设计与实现上的难度。实现这一系列不仅仅是技术上，而且也是软件工程上的难题。 页面生命周期综述 由上述对于输入与输出的讨论，我们可以理解 Chromium 团队提出以下有关于页面生命周期。 基于 Web Content 经过若干步骤产生相关数据模型。 数据模型随时间、交互等因素的不断更新。 其中，对于第二点要求尽可能少地快速地修改由初由第一步骤产生的数据模型，尽可能降低计算成本。其原因在于，第一步骤产生数据模型所进行的相关计算与数据模型的交互对于现有平均性能水平来说依然十分昂贵，所以不断重复执行第一步骤在实际环境中不可取。 初步渲染步骤概论 对于上面提及过的在输入与输出之间的相关步骤，我们将在下面按照前后顺序进行有关论述。 DOM 对于 HTML 来说，其语法规则有着明显的树状特征。这使得利用 HTML 能够方便地描述出文档结构并附带部分内容。所以我们需要提取出其中地结构信息与内容信息。在这一步中，HTML 文档解析器将解析 HTML 文档中的文本并转换其为 DOM 树。 有关于 DOM 树，不得不提的是 JavaScript 对于 DOM 树的操作能力，我认为这也是 JavaScript 的核心内容之一。JavaScript 借由该能力能够对页面进行控制、更新与内容添加、更改、删除等操作，我认为这是前后端分离思想的技术基础。上述能力对 DOM 树的实际操作由 V8 引擎具体完成，该引擎实现了 JavaScript 的操作 DOM 树的 API，使得 JavaScript 具备该能力。 ...

介绍 最近在研究有关 UNIX 的相关理论知识，在此记录相关重要概念备忘。 概述 伪终端是指，对于一个应用程序而言，它看似一个终端，但事实上它并不是一个真正的终端。 通常一个进程打开伪终端主设备，调用 fork。子进程建立一个新的会话，打开一个相应的伪终端从设备，将其文件描述符复制到标准输入输出错误，然后调用 exec。伪终端从设备称为子进程的控制终端。 看起来像一个双向管道，从设备上的终端行规程使得我们拥有普通管道没有的其他处理能力。 伪终端的典型用途 网络登录服务器 最典型的例子是 telnetd 和 rlogind 服务器。 在 rlogind 服务器和登录 shell 之间有两个 exec 调用，这是因为 login 程序通常在两个 exec 之间检验用户是否合法。 窗口系统终端模拟 终端模拟器最为 shell 和窗口管理器之间的媒介。每个 shell 在自己的窗口中执行。 shell 将自己的标准输入、标准输出、标准错误连接到 PTY 的从设备端。 script 程序 script 程序将终端会话期间的所有输入和输出信息复制到一个文件中。 使用 script 的不足是必须处理文件中的控制字符。 expect 程序 在非交互模式中驱动交互模式运行。 运行协同进程 当通过管道与协同进程通信时，标准 I/O 库会完全缓冲标准输入和标准输出，从而引起死锁。 现在协同进程的标准输入和标准输出就像终端设备一样，所以标准 I/O 库会将这两个流设置为行缓冲。 观看长时间运行程序的输出 由于重定向到文件时，标准 I/O 库将完全缓冲它的标准输出。 打开伪终端设备 PTY 表现得就像物理终端设备一样，因此应用程序就无需在意它们在使用的是何种设备。 在伪设备可用之前，它的权限必须设置，以便应用程序可以访问它。

介绍 我阅读并且学习了有关于 UNIX 系统终端 I/O 相关的内容。在此记录一些比较关键的概念。 引论 终端 I/O 十分复杂，原因之一是它应用于许多事物。 综述 终端 I/O 的两种工作模式：规范模式输入处理（默认）、非规范模式输入处理。 规范模式下，对于每一个读请求，终端驱动程序最多返回一行。 可以认为终端设备是由内核中的终端驱动程序控制的，每一个终端设备都有一个输入队列和一个输出队列。 开启回显功能时，在输入队列和输出队列之间有一个隐含连接。 输入队列长度是有限值。 输出队列虽然也有限，但是程序并不能获取这个值。在输出队列要填满时，内核会直接将写进程休眠。 大多是 UNIX 系统在一个称为终端行规程的模块中进行全部的规范处理。该模块在内核通用读写函数和实际设备驱动程序之间。 所有可以检测和更改的终端设备特性都包含在 termios 结构中。 使用 tcsetattr 和 tcgetattr 可以设置终端选项进而控制终端。 特殊输入字符 POSIX 定义了 11 个在输入时要特殊处理的字符。在这 11 个特殊字符中，9 个字符的值可以任意更改。 为了更改特殊字符，需要修改 termios 结构中的 c_cc 数组的相应项。 POSIX 允许禁止使用这些字符。 终端标识 在大多数 UNIX 系统版本中，控制终端名字一直是/dev/tty。 规范模式与非规范模式 规范模式：发送一个请求，当一行已经输入以后，终端程序立即返回。以下几个条件造成读返回： 所请求的字节数已经读到时，无需读一个完整的行。 当读到一个行界定符号 捕捉到信号，并且该函数不再自动重启 非规范模式：时输入数据不装配成行，不处理特殊字符。当读取指定量的数据后，或者超过指定量的时间后，通知系统返回。该模式下没有关闭对信号的处理，用户始终可以键入一个触发终端产生信号的字符。 终端窗口大小 大多数 UNIX 系统都提供了一种跟踪当前终端窗口大小的方法，当窗口大小变化的时候，使内核通知前台进程组。内核未每个终端和伪终端都维护了一个 winsize 结构。