TTY 是 TeleTYpe（电传打字机）的缩写，这一诞生于 19 世纪的通信设备在 Unix 系统中以软件抽象的形式延续至今。尽管现代开发者更多通过伪终端（PTY）间接与 TTY 层交互，但理解其内部机制对于调试终端应用、实现交互式 CLI、处理信号控制字符等场景仍具有重要的工程价值。本文将从行纪律（line discipline）的角度切入，解析 Linux 终端子系统的缓冲处理与信号生成逻辑。
三层架构与行纪律的定位
Linux 终端子系统采用三层架构设计，从上到下依次为：字符设备接口层、行纪律层（line discipline）以及硬件驱动层。行纪律层扮演着胶水角色的中间件，它将底层串口驱动的原始字节流转换为符合特定语义的字符序列，同时向上层应用提供统一的读写接口。这种设计实现了机制（mechanism）与策略（policy）的分离，使得同一套串口驱动可以适配不同的行纪律实现。
从数据流向来看，输入数据首先由硬件驱动接收并放入 flip buffer，随后通过 receive_buf 回调函数传递给行纪律层处理。行纪律层根据当前配置对字符进行回显、编辑、控制字符识别等操作，最终将处理后的数据放入内部环形缓冲，等待应用程序通过 read 系统调用读取。输出方向则相反，应用程序的 write 调用首先到达行纪律层，经过处理后转发给底层驱动发送至终端。这种双向数据流经过行纪律层的事实，正是终端能够实现「输入回显」「行编辑」等语义的技术基础。
N_TTY：默认行纪律的实现
Linux 内核默认的行纪律实现是 N_TTY，它遵循 POSIX 规范处理终端 I/O。N_TTY 相关的核心代码位于 drivers/tty/n_tty.c，其操作接口定义在 include/linux/tty_ldisc.h 中的 tty_ldisc_ops 结构体。该结构体包含约 20 个回调函数指针，覆盖了行纪律的完整生命周期。
open 函数在行纪律被绑定到 TTY 设备时调用，负责初始化内部状态并设置 tty->receive_room 为行纪律单次愿意接收的最大数据量。close 函数则在对端关闭或切换行纪律时触发，执行清理工作。receive_buf 是最关键的输入处理函数，驱动层通过它将原始字符数据传递给行纪律；对应的 write_wakeup 则用于通知驱动层可以接收更多输出数据。read 和 write 函数分别处理用户空间的读写请求，而 ioctl 则转发未被 TTY 核心层处理的设备控制请求。
值得注意的是，行纪律编号是用户空间 ABI 的一部分，文档明确警告不得重用已有的行纪律编号，否则可能导致系统不稳定。这一设计决策源于 Unix 系统对向后兼容性的严格要求。
规范模式与原始模式的区别
规范模式（canonical mode），又称 cooked mode，是行纪律最常见的工作状态。在此模式下，行纪律维护一个 4KB 的内部环形缓冲（N_TTY_BUF_SIZE），用于暂存用户输入的字符。应用程序的 read 调用在未收到换行符（LF，即 ^J）之前不会返回，这意味着用户可以在输入过程中进行行内编辑。退格键（默认为 ^? 或 Delete）删除前一个字符，组合键 ^U 则擦除整行内容。当用户按下回车键时，输入的 CR 字符（Enter 键默认产生）在 icrnl 标志启用的情况下会被转换为 LF，随后整行数据被交付给应用程序。
原始模式（raw mode）则是规范模式的反面。当 -icanon 标志被设置时，行纪律不再维护行缓冲，read 调用会在任意时刻返回可用的数据，回显和行编辑功能也随之禁用。特殊控制字符不再触发信号或编辑行为，应用程序收到的就是按键的真实扫描码序列。这种模式对于实现全屏交互应用（如 vim、less）或自定义输入处理至关重要。
stty raw 命令实际上是一系列标志位的组合简写，它同时关闭了规范模式（-icanon）、信号处理（-isig）以及 CR 到 LF 的自动转换（-icrnl）。直接使用 stty -icanon -isig -icrnl 可以获得与 stty raw 几乎完全相同的行为，理解这种对应关系有助于在脚本中精确控制终端状态。
缓冲机制与 Flip Buffer
除了行纪律内部的环形缓冲外，TTY 子系统还存在另一层缓冲机制：flip buffer。flip buffer 位于驱动层与行纪律层之间，用于暂存从硬件接收的原始数据。当驱动层收到新数据时，它调用 tty_insert_flip_string 或 tty_insert_flip_string_flags 将字符放入 flip buffer，然后通过 tty_flip_buffer_push 通知行纪律层读取。flip buffer 采用双缓冲（double buffering）设计，驱动在一块缓冲区填充数据时，行纪律可以并发读取另一块缓冲区，这种无锁设计优化了高吞吐量场景下的性能表现。
flip buffer 的设计还涉及到流控（flow control）机制。当输出端无法及时处理数据时，它可以通过设置 tty->flow.stopped 标志并向对端发送 XOFF（Ctrl+S）字符，请求暂停传输；对端收到 XOFF 后停止发送，待收到 XON（Ctrl+Q）后恢复。这种软件流控机制在串口通信中尤为重要，可以防止数据因接收方处理不及而丢失。
控制字符与信号生成
行纪律的处理逻辑中，控制字符的识别与信号生成是两个紧密关联的功能。当 isig 标志启用时，特定的控制字符会被转换为信号并发送给前台进程组。默认配置下，^C（ASCII 0x03）触发 SIGINT 中断进程，^\（Ctrl+backslash）触发 SIGQUIT 退出进程并生成 core dump，^Z（Ctrl+Z，在某些配置下）触发 SIGTSTP 暂停进程。这些语义使得用户可以通过简单的键盘组合控制程序的执行状态。
值得注意的是，控制字符的键位映射可以通过 termios 接口自定义。VINTR、VQUIT、VERASE、VKILL、VSTART、VSTOP 等 termios 字段分别对应不同的控制字符，通过 tcgetattr 和 tcsetattr 函数可以查询和修改这些映射。例如，将中断字符从 ^C 改为 ^A 可以使用 stty intr ^a 或相应的 C API 调用。这种灵活性在某些特殊场景下具有实用价值。
工程实践与配置建议
在工程实践中，调试 TTY 相关问题通常需要从 termios 配置入手。stty -a 命令可以显示当前终端的所有配置标志，配合 sudo cat /proc/tty/ldiscs 可以查看系统当前加载的行纪律列表。对于需要临时切换到原始模式的场景，建议在脚本中使用 stty raw 进入原始模式，并在退出时使用 stty sane 或保存原始配置后恢复，以避免终端陷入不可用状态。
行纪律缓冲溢出是一个容易被忽视的问题。由于规范模式下的行缓冲固定为 4KB，当用户输入超过这一长度时，新字符会被静默丢弃，应用程序只会收到前 4096 个字符。这一行为在需要长文本输入的场景下可能导致数据丢失，解决方案包括增大缓冲上限或使用 readline 等用户空间库自行管理输入缓冲。在原始模式下同样存在缓冲溢出的风险，如果应用程序读取速度跟不上输入速度，环形缓冲同样会溢出，此时需要从应用层面优化读取逻辑或调整缓冲参数。
TTY 子系统的设计虽然可以追溯到半个世纪前，但其核心机制 —— 行纪律、缓冲管理、信号生成 —— 在今天依然支配着 Linux 终端的行为逻辑。理解这些底层细节，不仅有助于排查交互式应用的终端问题，也为设计新的字符设备驱动或终端模拟器提供了参考范式。
参考资料
- Linux Kernel Documentation：TTY Line Discipline（https://docs.kernel.org/driver-api/tty/tty_ldisc.html）
- Jonathan Lam：Understanding the tty subsystem: Line discipline（https://lambdalambda.ninja/blog/56/）