简介Moxa RealTTY 系列 Linux 驱动源码包面向需要将远程串口设备映射为本地真实端口的运维与内核开发者。源码基于 npreal2 驱动整理补丁来自 AUR 仓库并按内核版本拆分为 4.x/5.x 分支各分支还附带对应版本的内核适配说明省去自行收集补丁的兼容性工作patch 重点修复 proc_dir_entry 到 proc_ops、access_ok 参数变化等接口问题C 代码则覆盖主驱动、冗余服务、动态添加/删除串口和安全配置等核心逻辑。压缩包共含 35 个文件以 C/头文件、补丁、说明文本和脚本为主另有 mod、orig/rej 等编译产物与修改对照readme、SUPPORT、VERSION 等文本说明版本匹配与已知问题整体仅 132KB结构紧凑。mknod/rmnod、inst/uninst 等脚本可完成设备节点创建、安装与卸载Makefile 简化了内核模块编译流程部署时可减少手工操作。已有 311 人学习适合需要维护旧版 Moxa 串口终端或移植 npreal2 驱动的中级以上 Linux 开发者。1. 为什么要把远程串口变成本地 ttynpreal2 与 Moxa RealTTY 的定位想象一个场景一台 Linux 服务器放在机房几十米外的产线上挂着一台只有 RS232 串口的老式仪表你需要让服务器上的业务程序直接去读写这台仪表。最原始的做法是 SSH 到产线旁边的工控机上操作但业务程序不认这种间接访问你需要的是一块“虚拟串口网卡”——应用层写/dev/ttyS0一样写/dev/ttyNPR0数据自己走网线到串口服务器再从串口服务器出来。这就是 npreal2 干的事它是 Moxa RealTTY 技术方案在 Linux 下的驱动程序把 NPort 系列串口服务器映射成本地的 tty 设备。适合谁用做工业采集、边缘网关、设备联网的老哥们尤其是程序里已经写死串口路径、不想大改通信层的场景。2. 架构设计数据从设备串口到本地 tty 的五层链路2.1 驱动要解决的三个问题要把一个远程串口伪装成本地串口实际要跨过三层障碍这是我把整个驱动拆开后才理清的。第一层是语义问题。Linux 应用对串口的认知是open / read / write / ioctl加termios参数这套语义由内核 tty 子系统提供。驱动必须向 tty 子系统注册一个完整的字符设备驱动实现 open、write、write_room 这些回调并且要处理波特率、数据位、流控这些参数否则应用层用stty和termios配置串口时会直接失败。第二层是连接问题。NPort 串口服务器本质上是一个 TCP 服务端监听 4001 这类端口把收到的网络数据转成串口电平。驱动这边要维护一条或多条 TCP socket 连接还得处理设备重启、网线断开、半开连接这些异常情况。串口设备的连接没有心跳概念网线断了驱动可能还傻傻等数据必须自己实现超时和重连机制。第三层是搬运问题。数据是双向的应用 write 到 tty 的数据要经过驱动发到 socketsocket 收上来的数据要灌进 tty 子系统的读队列。这里有个约束内核里很多路径不能睡眠但 socket 收发可能阻塞所以读写路径不能一股脑全塞在同一个上下文里。搞明白这三层整个项目就拆成 tty 接口、网络收发、缓冲管理三个模块后面看代码就不乱了。2.2 源码目录结构与模块划分拿到源码包后我习惯先把文件树列出来看粒度。我拆的这份代码结构大致如下npreal2/ ├── npr2_main.c # 模块入口tty_driver 注册模块参数解析 ├── npr2_tty.c # tty_operations 回调open/release/write/ioctl ├── npr2_net.c # TCP socket 建立、收发线程、断线重连 ├── npr2_buffer.c # 环形缓冲区与字符计数 ├── npr2_proc.c # /proc/npreal2 调试节点 ├── npr2.h # 公共结构体与常量定义 └── Makefile这个文件划分是有讲究的。npr2_main.c只管生命周期——加载、卸载、解析模块参数npr2_tty.c只跟 tty 子系统打交道不碰网络npr2_net.c只负责把串口数据变成 TCP 流量。驱动开发最容易翻车的地方就是模块之间互相直接访问内部数据最后改一个功能牵一发动全身。这里用struct npr2_port作为共享上下文每个端口一个实例tty 和 net 都持有它的指针但各自只改自己负责的字段。2.3 端口对象与模块参数的数据结构整个驱动的心脏是端口对象它把 tty 端口、socket、缓冲区三样东西绑在一起。看看npr2.h里核心结构体的典型定义#define NPR2_MAX_PORTS 32 #define NPR2_TX_BUFSIZE 4096 struct npr2_port { struct tty_port port; /* tty 子系统端口对象 */ struct socket *sock; /* 到 NPort 的 TCP 连接 */ struct task_struct *rx_task; /* 内核收包线程 */ spinlock_t lock; /* 保护缓冲区与计数字段 */ wait_queue_head_t wq; /* 发送线程等待队列 */ unsigned char ip[16]; /* NPort 设备 IP */ unsigned short net_port; /* NPort 监听端口 */ unsigned int baud; /* 串口波特率 */ unsigned char data_bits; /* 数据位 5/6/7/8 */ unsigned char parity; /* 校验位 */ unsigned char stop_bits; /* 停止位 */ unsigned int rx_bytes; /* 统计接收字节数 */ unsigned int tx_bytes; /* 统计发送字节数 */ unsigned int link_state; /* 链路状态 0/1 */ }; static struct npr2_port *npr2_ports[NPR2_MAX_PORTS];struct tty_port是内嵌对象不是指针这一点很关键。老式 tty 驱动经常自己维护一堆引用计数和互斥锁而新内核建议把端口状态交给tty_port管理open/close 的竞态它会帮你兜底。rx_task是内核线程指针因为 socket 收数据是阻塞的不能放在软中断或者工作队列里长期占用。link_state是给上层诊断用的后面二次开发加统计接口时直接读它。模块参数加载方式是这个驱动的特色RealTTY 方案通常不用设备树或配置文件而是靠insmod时传参一次性把所有端口的连接信息传给驱动static unsigned int npr2_count 1; module_param(npr2_count, uint, 0444); static char *npr2_ip[NPR2_MAX_PORTS]; module_param_array(npr2_ip, charp, NULL, 0444); static int npr2_net_port[NPR2_MAX_PORTS] {4001}; module_param_array(npr2_net_port, int, NULL, 0444); static int npr2_baud[NPR2_MAX_PORTS] {115200}; module_param_array(npr2_baud, int, NULL, 0444);npr2_count决定注册多少个 tty 设备npr2_ip和npr2_net_port决定每个设备连接哪台 NPort 的哪个端口npr2_baud是默认串口速率。多端口场景下用逗号分隔npr2_ip192.168.0.10,192.168.0.11。需要特别注意的是module_param_array对 charp 类型只填第一个元素如果数组长度超过传入个数后面的元素保持默认值。我之前就吃过这个亏后面避坑章节详细讲。3. 核心代码拆解从模块加载到 open/write 的完整调用链3.1 模块入口与 tty_driver 注册驱动加载时要做的事情很直接分配端口对象、构造 tty 驱动实例、注册进内核。看npr2_main.c里模块初始化函数的典型写法static struct tty_driver *npr2_tty_driver; static int __init npr2_init(void) { int ret; ret npr2_alloc_ports(); if (ret) return ret; npr2_tty_driver tty_alloc_driver(npr2_count, TTY_DRIVER_REAL_RAW); if (IS_ERR(npr2_tty_driver)) return PTR_ERR(npr2_tty_driver); npr2_tty_driver-driver_name npreal2; npr2_tty_driver-name ttyNPR; npr2_tty_driver-major 240; npr2_tty_driver-minor_start 0; npr2_tty_driver-type TTY_DRIVER_TYPE_SERIAL; npr2_tty_driver-subtype SERIAL_TYPE_NORMAL; npr2_tty_driver-init_termios tty_std_termios; npr2_tty_driver-init_termios.c_cflag B115200 | CS8 | CREAD | HUPCL | CLOCAL; npr2_tty_driver-init_termios.c_ispeed 115200; npr2_tty_driver-init_termios.c_ospeed 115200; tty_set_operations(npr2_tty_driver, npr2_tty_ops); ret tty_register_driver(npr2_tty_driver); if (ret) { tty_driver_kref_put(npr2_tty_driver); return ret; } npr2_proc_init(); pr_info(npreal2: %u port(s) registered as ttyNPR0..ttyNPR%d\n, npr2_count, npr2_count - 1); return 0; } module_init(npr2_init);这个函数里有几个值得注意的参数。TTY_DRIVER_REAL_RAW标志告诉 tty 层这个驱动提供的是原始字节通道不要对它做行规程的缓冲处理否则数据会在 tty 层被拆成行、加上回显工控二进制帧直接就废了。driver-name设为ttyNPR设备节点就会自动命名为ttyNPR0、ttyNPR1这样。major 240是固定主设备号如果你机器上的 240 被占了改成 0 让内核动态分配也行但动态分配后 mknod 和 udev 规则都要跟着变我一般固定一个不冲突的号。init_termios里面B115200 | CS8 | CREAD | HUPCL | CLOCAL是串口驱动最常用的组合B115200 表示波特率常量CS8 是 8 位数据位CREAD 开启接收CLOCAL 表示忽略 modem 控制线HUPCL 是最后一个进程关闭设备时挂断连接。这段默认参数非常重要因为它决定了业务程序不调用 tcsetattr 直接读写时驱动工作在什么模式下。卸载函数对应做逆操作tty_unregister_driver、tty_driver_kref_put、释放端口顺序不能乱。内核里模块卸载时如果还有进程持有设备文件tty 层会返回 -EBUSY所以驱动里还要在 release 回调里把 socket 关掉、把收包线程停掉这套逻辑在npr2_tty_release里。3.2 open 时建立 TCP 链路与 termios 初始化业务程序open(/dev/ttyNPR0)时tty 子系统的 open 流程会一路调到驱动的 open 回调。这个时机也是建立 TCP 连接的最佳位置——只有应用真正要用串口的时候才去连设备而不是模块加载时就全部连一遍。不过要注意 open 是进程上下文可以睡眠所以可以放心在里面做 socket 连接static int npr2_open(struct tty_struct *tty, struct file *filp) { struct npr2_port *p; if (tty-index npr2_count) return -ENODEV; p npr2_ports[tty-index]; tty-driver_data p; if (!p-sock) { int ret npr2_net_connect(p); if (ret) { pr_err(npreal2: port %d connect failed, err%d\n, tty-index, ret); return ret; } } tty-termios.c_iflag ~(IXON | IXOFF | ICRNL | INLCR); tty-termios.c_lflag ~(ICANON | ECHO | ISIG); return 0; }tty-driver_data是 tty 层留给驱动挂私有数据的指针后面的 write、ioctl 回调全靠它把 tty 和端口对象关联起来。npr2_net_connect里面做的是标准内核 socket 流程sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP, p-sock)然后设置sk_sndtimeo和sk_rcvtimeo超时再kernel_connect。NPort 的串口服务器工作在 TCP Server 模式驱动这边是 Client 主动连它。open 回调里我特别喜欢做一件事就是强制把 termios 的输入标志和本地标志清掉。为什么要这样因为 tty 默认的行规程会把收到的0x0D转成0x0A会把 XON/XOFF 字符当成流控吞掉如果业务程序读写的是二进制协议这些转换会让数据帧永远对不齐。我在 open 里直接关掉 IXON/IXOFF/ICRNL/ICANON/ECHO相当于给每个应用默认开了 raw 模式省得他们每次都要自己写stty raw。3.3 写路径应用 write 到 socket 发送应用的write(fd, buf, len)经过 tty 层最终会落到驱动的写回调。这个回调要注意它运行在进程上下文可以睡眠所以可以直接做阻塞的kernel_sendmsg。但因为 TCP 发送不一定一次能发完必须循环发送完整包static ssize_t npr2_write(struct tty_struct *tty, const unsigned char *buf, size_t count) { struct npr2_port *p tty-driver_data; size_t sent 0; int ret; if (!p-sock || !p-link_state) return -EIO; while (sent count) { struct kvec iov { .iov_base (void *)(buf sent), .iov_len count - sent, }; ret kernel_sendmsg(p-sock, p-msg, iov, 1, count - sent); if (ret 0) { if (ret -ERESTARTSYS) break; return sent ? sent : ret; } sent ret; } p-tx_bytes sent; return sent; }kernel_sendmsg的返回值是实际发送的字节数可能小于请求长度。驱动必须把已发送的数量返回给 tty 层tty 层才能从写缓冲里裁剪掉这些字节否则应用会以为数据没写完下次重发造成重复。如果返回错误码也要原样上传用户态write会拿到 -1 和对应的 errno。这里有个小细节-ERESTARTSYS表示系统调用被信号打断tty 层会优雅地重启这次写操作所以我在这个错误码上只是 break不把它当成致命错误上报。这里没有引入发送线程因为写路径本身就是进程上下文直接在 tty 线程里做 send 就够了加了线程反而要面对唤醒和缓冲的竞态。3.4 读路径内核收包线程与 flip buffer 推送读方向就完全是另一套逻辑了。socket 收数据不能像写路径那样借用进程上下文——数据是 NPort 主动推过来的没有对应的应用进程在等着。所以驱动必须开一个内核线程常年阻塞在kernel_recvmsg上等数据。收到数据后要把它灌进 tty 子系统的 flip buffer再推给可能正在阻塞读的应用static int npr2_rx_thread(void *arg) { struct npr2_port *p (struct npr2_port *)arg; unsigned char buf[4096]; struct tty_struct *tty; while (!kthread_should_stop()) { struct kvec iov { .iov_base buf, .iov_len sizeof(buf), }; int len kernel_recvmsg(p-sock, p-msg, iov, 1, sizeof(buf), 0); if (len 0) { if (len -ERESTARTSYS) continue; npr2_net_break(p); break; } tty tty_port_tty_get(p-port); if (tty) { tty_insert_flip_string_fixed_flag(tty, buf, TTY_NORMAL, len); tty_flip_buffer_push(tty); tty_kref_put(tty); } p-rx_bytes len; } return 0; }tty_port_tty_get是拿当前打开这个端口的 tty 对象同时增加一次引用计数。这个引用必须配对tty_kref_put,否则端口被 close 时 tty 对象释放不掉设备文件会一直被占用。tty_insert_flip_string_fixed_flag是批量化插入数据的接口TTY_NORMAL表示这些字节都是正常数据而不是 break 或帧错误。插入完成后必须调用tty_flip_buffer_push它会把 flip buffer 里的数据推到行规程继而唤醒正在read阻塞的进程。这个过程要注意如果你在中断上下文push 必须用tty_flip_buffer_push的 atomic 版本我们是内核线程用普通版本没问题。npr2_net_break做的事情是把p-link_state置 0、关闭 socket、置空p-sock然后等待下次 open 时重新连接。串口设备断线后业务程序的 read 可能会永久阻塞所以有些版本的驱动会在断线时向 tty 发送挂断信号让应用感知到链路异常这属于可选的增强行为。4. 编译部署从源码到 /dev/ttyNPR0 的完整流程4.1 编译前的内核头文件准备拿到源码后先别急着 make先确认当前环境能不能编译内核模块。内核模块编译必须依赖当前内核的构建目录检查方法很简单uname -r ls -l /lib/modules/$(uname -r)/build如果/lib/modules/$(uname -r)/build不存在或者指向空目录说明没装内核头文件。Debian/Ubuntu 系装linux-headers-$(uname -r)RedHat 系装kernel-devel。这里经常有人栽跟头自己下了内核源码包PATH 也配了但 Makefile 里的 KERNELDIR 指向的是/lib/modules/$(shell uname -r)/build这个路径是软链接它必须指向与当前运行内核完全一致的构建树版本号差一个小版本都会导致 insmod 失败。4.2 Makefile 与内核模块编译驱动源码里自带的 Makefile 一般长这样obj-m指定要构建的模块多文件目标用-objs列出所有源文件obj-m : npreal2.o npreal2-objs : npr2_main.o npr2_tty.o npr2_net.o npr2_proc.o KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean注意 Makefile 里all和clean下面的命令行必须是 Tab 缩进不能用空格。然后直接执行make编译完成后当前目录会生成npreal2.ko这就是最终要加载的内核模块。编译过程中如果报错九成是头文件路径不对或内核源码版本与运行版本不一致先把make clean再做一遍别在旧 .o 文件上反复排查。4.3 模块参数与 insmod 加载单端口场景最简单加载命令把 NPort 的 IP、端口、波特率三个参数传进去sudo insmod npreal2.ko npr2_count1 \ npr2_ip192.168.0.10 \ npr2_net_port4001 \ npr2_baud115200多端口场景用逗号分隔每组参数一一对应sudo insmod npreal2.ko npr2_count2 \ npr2_ip192.168.0.10,192.168.0.11 \ npr2_net_port4001,4001 \ npr2_baud115200,9600加载成功后执行ls /dev/ttyNPR*应该能看到ttyNPR0和ttyNPR1没有的话先看 dmesgdmesg | tail -20insmod和modprobe的区别这里要提一句insmod不解析依赖、不读/etc/modprobe.d配置如果你要固定参数持久化加载应该把参数写进/etc/modprobe.d/npreal2.conf然后用modprobe npreal2。我一般调试期用 insmod上生产用 modprobe避免重启后设备节点不在了。4.4 udev 规则与基础验证模块加载后生成的设备节点默认属主是 root:root普通用户打不开。写一条 udev 规则固定权限创建/etc/udev/rules.d/99-npreal2.rulesKERNELttyNPR*, MODE0666如果要限制到特定用户组把MODE0666改成MODE0660 GROUPdialout然后把业务用户加入 dialout 组。改完执行udevadm control --reload-rules让它生效。第一次验证建议直接用stty配 raw 模式然后 echo 一下。NPort 串口侧如果做了 TX/RX 短接回环那么下面这条命令应该能收到自己发出去的数据stty -F /dev/ttyNPR0 115200 raw -echo echo hello /dev/ttyNPR0 timeout 1 cat /dev/ttyNPR0如果 cat 有输出说明链路是通的TCP 连接、tty 注册、读写路径都正常。如果没有输出先别怀疑驱动用nc或telnet直接连 NPort 的 IP 和端口看串口服务器本身是否正常转发。这套排查顺序能帮你快速定位是驱动问题还是网络设备问题。5. 排查手记加载失败、粘包与 termios 设不上的 5 个实战问题5.1 insmod 报 Exec format error现象insmod npreal2.ko提示Exec format errordmesg 里跟着一行version magic x.x.x should be y.y.y。原因编译用的内核头文件版本与当前运行内核不一致。最常见的是你下载的内核源码树和/lib/modules/$(uname -r)/build指向的不是同一套东西Makefile 里的 KERNELDIR 写死了某个旧路径或者编译机器和运行机器内核版本不同。解决先uname -r确认运行版本再确认/lib/modules/$(uname -r)/build存在且指向正确。如果是交叉编译场景Makefile 里 KERNELDIR 要显式指定目标机的内核构建目录不能依赖 SHELL 变量。然后make clean重编看 vermagic 是否一致。我吃过这个亏后来养成了编译前先ls -l /lib/modules/$(uname -r)/build看一眼目标的习惯。5.2 open 设备返回 -EIO 或应用卡死在 open现象设备节点存在但业务程序 open 报No such device or address或者 open 成功但 read 永远不返回dmesg 里有connect failed, err-113。原因open 回调里懒连接建立 TCP 连接失败了。-113是EHOSTUNREACH,常见于 IP 写错、网段不通、NPort 设备没开机。还有一种是 NPort 被配置成了 RFC2217 模式或 UDP 模式驱动拿裸 TCP 去连协议对不上连接建了也被断掉。解决先nc -vz IP port从服务器测 TCP 连通性通的话直接用nc IP port连上去看有没有串口数据回流。如果 nc 能通而驱动连不上检查模块参数里npr2_ip和npr2_net_port是不是真的传进去了cat /sys/module/npreal2/parameters/npr2_ip看一眼。NPort 的 Work mode 要设成 TCP ServerTCP alive timeout 配成一个合理的值别让半开连接挂在那。5.3 write_room 为 0应用数据写不出去现象业务程序write返回值一直是 0或者 tty 层的写缓冲永远满驱动 write 回调根本没被调用。原因驱动没有实现write_room回调或者实现里恒返回 0。tty 子系统通过write_room判断驱动还能吞下多少字节返回 0 它就认为没有空间直接暂停写入应用层表现为写不进去。解决实现write_room返回环形缓冲区的剩余空间static unsigned int npr2_write_room(struct tty_struct *tty) { struct npr2_port *p tty-driver_data; return NPR2_TX_BUFSIZE - npr2_tx_used(p); }同时保证在发送线程消费完数据后调用tty_wakeup(tty)唤醒等待写入的进程。这个回调不是可选优化是 tty 驱动必须实现的漏了就是写不动的玄学故障。入库前建议把所有 tty_operations 回调列个表逐一核对凡是串口驱动该有的 open/release/write/write_room/ioctl 一个都不能少。5.4 数据能通但第一字节丢失或乱码现象cat 设备能看到 NPort 那边发来的数据但开头几个字节是 0x00或者二进制帧里某些字节神秘消失。原因termios 默认的行规程正在做“好事”——把0x0D转成0x0A把 XON/XOFF 字符当流控吞掉ICRNL把回车当换行。如果业务程序没设置 raw 模式这些转换会破坏任何二进制协议。这不是驱动收发的 bug是 tty 层在中间做了手脚排查起来特别像玄学。解决open 回调里强制清除IXON | IXOFF | ICRNL | INLCR输入标志和ICANON | ECHO | ISIG本地标志把所有端口默认设为 raw 模式。验证的时候先stty -F /dev/ttyNPR0 raw再跑业务程序。我曾经在一个设备联网项目里被这个问题搞了整整一天线上数据帧怎么都对不齐最后发现是 termios 默认把0x03字符当成信号处理了从那以后我写串口驱动必做一件事open 时直接把 termios 刷成 raw绝不依赖应用自己去设置。5.5 多端口参数相互覆盖现象npr2_count2加载后两个 ttyNPR 设备连的都是同一台 NPort改第二个端口的参数第一个跟着变。原因module_param_array对charp数组的处理有坑。npr2_ip192.168.0.10,192.168.0.11这种写法只有加载时传了两个值数组才有两个元素如果你只传了一个 IP第二个元素是 NULL驱动里用strcpy或者strcmp时直接崩或者 fallback 到默认值两个设备就指向了同一个 IP。端口号数组也有类似问题只给一个4001第二个端口也默认 4001两台 NPort 就撞车了。解决驱动初始化时对每个端口的参数做收敛检查和默认值回填然后往/proc/npreal2输出一张端口参数表。加载时写全参数别省逗号sudo insmod npreal2.ko npr2_count2 \ npr2_ip192.168.0.10,192.168.0.11 \ npr2_net_port4001,4001 \ npr2_baud115200,9600加载完先cat /proc/npreal2对一遍端口数量和 IP确认没问题再起业务。6. 实战改造给驱动加一个动态改波特率与诊断统计的 ioctl很多工控场景里串口设备的波特率不是永远不变的上位机软件可能需要在运行中切换。RealTTY 驱动如果只靠模块参数定死波特率业务层就不得不重启驱动来改参数这在生产环境是不可接受的。比较好的方案是给驱动补两个 ioctl一个动态改波特率一个读链路统计。先定义用户态和驱动共享的协议头#define NPR2_MAGIC R #define NPR2_IOCSBAUD _IOW(NPR2_MAGIC, 1, int) #define NPR2_IOCGSTAT _IOR(NPR2_MAGIC, 2, struct npr2_stats) struct npr2_stats { __u32 rx_bytes; __u32 tx_bytes; __u32 rx_count; __u32 tx_count; __u32 link_state; __u32 dropped; };驱动侧在tty_operations里挂 ioctl 回调实现分发static int npr2_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned long arg) { struct npr2_port *p tty-driver_data; int baud; switch (cmd) { case NPR2_IOCSBAUD: if (copy_from_user(baud, (void __user *)arg, sizeof(baud))) return -EFAULT; return npr2_set_baud(p, baud); case NPR2_IOCGSTAT: { struct npr2_stats st { .rx_bytes p-rx_bytes, .tx_bytes p-tx_bytes, .link_state p-link_state, }; if (copy_to_user((void __user *)arg, st, sizeof(st))) return -EFAULT; return 0; } default: return -ENOIOCTLCMD; } }copy_from_user和copy_to_user是内核态和用户态传数据的标准接口不能用 memcpy。npr2_set_baud里先校验波特率是否在合法范围内合法就更新p-baud如果连接的 NPort 支持 RFC2217 协议还可以通过 socket 给设备发一条波特率切换指令让串口服务器侧同步切换。不支持的话就只能改本地参数实际波特率需要到 NPort 的 Web 管理页手动改。生产环境里的做法是优先用 RFC2217,实在不支持再说。改造完成后写一个几十行的用户态工具验证open 设备ioctl(fd, NPR2_IOCGSTAT, st)读统计ioctl(fd, NPR2_IOCSBAUD, baud)改波特率然后看/proc/npreal2里的状态是否同步变化。这比反复 insmod/rmmod 验证参数靠谱得多也让业务程序有了运行时调整的手段。另外提醒一句老内核里tty_operations的 ioctl 回调现在正逐渐移到tty_port_operations里如果你要移植到新内核先查当前内核版本对应的接口位置别照抄老代码。我早期给某边缘网关项目做驱动改造时因为没有提前留诊断接口现场调参只能靠重启大法来回折腾了好几轮——从那以后我每次写串口驱动第一个版本就先把统计计数和动态配置类的 ioctl 铺好调试手段永远比功能先到位希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 4:19:53 · 阅读 1.2k npreal2驱动实战：Moxa远程串口映射为本地tty设备
简介Moxa RealTTY 系列 Linux 驱动源码包面向需要将远程串口设备映射为本地真实端口的运维与内核开发者。源码基于 npreal2 驱动整理补丁来自 AUR 仓库并按内核版本拆分为 4.x/5.x 分支各分支还附带对应版本的内核适配说明省去自行收集补丁的兼容性工作patch 重点修复 proc_dir_entry 到 proc_ops、access_ok 参数变化等接口问题C 代码则覆盖主驱动、冗余服务、动态添加/删除串口和安全配置等核心逻辑。压缩包共含 35 个文件以 C/头文件、补丁、说明文本和脚本为主另有 mod、orig/rej 等编译产物与修改对照readme、SUPPORT、VERSION 等文本说明版本匹配与已知问题整体仅 132KB结构紧凑。mknod/rmnod、inst/uninst 等脚本可完成设备节点创建、安装与卸载Makefile 简化了内核模块编译流程部署时可减少手工操作。已有 311 人学习适合需要维护旧版 Moxa 串口终端或移植 npreal2 驱动的中级以上 Linux 开发者。1. 为什么要把远程串口变成本地 ttynpreal2 与 Moxa RealTTY 的定位想象一个场景一台 Linux 服务器放在机房几十米外的产线上挂着一台只有 RS232 串口的老式仪表你需要让服务器上的业务程序直接去读写这台仪表。最原始的做法是 SSH 到产线旁边的工控机上操作但业务程序不认这种间接访问你需要的是一块“虚拟串口网卡”——应用层写/dev/ttyS0一样写/dev/ttyNPR0数据自己走网线到串口服务器再从串口服务器出来。这就是 npreal2 干的事它是 Moxa RealTTY 技术方案在 Linux 下的驱动程序把 NPort 系列串口服务器映射成本地的 tty 设备。适合谁用做工业采集、边缘网关、设备联网的老哥们尤其是程序里已经写死串口路径、不想大改通信层的场景。2. 架构设计数据从设备串口到本地 tty 的五层链路2.1 驱动要解决的三个问题要把一个远程串口伪装成本地串口实际要跨过三层障碍这是我把整个驱动拆开后才理清的。第一层是语义问题。Linux 应用对串口的认知是open / read / write / ioctl加termios参数这套语义由内核 tty 子系统提供。驱动必须向 tty 子系统注册一个完整的字符设备驱动实现 open、write、write_room 这些回调并且要处理波特率、数据位、流控这些参数否则应用层用stty和termios配置串口时会直接失败。第二层是连接问题。NPort 串口服务器本质上是一个 TCP 服务端监听 4001 这类端口把收到的网络数据转成串口电平。驱动这边要维护一条或多条 TCP socket 连接还得处理设备重启、网线断开、半开连接这些异常情况。串口设备的连接没有心跳概念网线断了驱动可能还傻傻等数据必须自己实现超时和重连机制。第三层是搬运问题。数据是双向的应用 write 到 tty 的数据要经过驱动发到 socketsocket 收上来的数据要灌进 tty 子系统的读队列。这里有个约束内核里很多路径不能睡眠但 socket 收发可能阻塞所以读写路径不能一股脑全塞在同一个上下文里。搞明白这三层整个项目就拆成 tty 接口、网络收发、缓冲管理三个模块后面看代码就不乱了。2.2 源码目录结构与模块划分拿到源码包后我习惯先把文件树列出来看粒度。我拆的这份代码结构大致如下npreal2/ ├── npr2_main.c # 模块入口tty_driver 注册模块参数解析 ├── npr2_tty.c # tty_operations 回调open/release/write/ioctl ├── npr2_net.c # TCP socket 建立、收发线程、断线重连 ├── npr2_buffer.c # 环形缓冲区与字符计数 ├── npr2_proc.c # /proc/npreal2 调试节点 ├── npr2.h # 公共结构体与常量定义 └── Makefile这个文件划分是有讲究的。npr2_main.c只管生命周期——加载、卸载、解析模块参数npr2_tty.c只跟 tty 子系统打交道不碰网络npr2_net.c只负责把串口数据变成 TCP 流量。驱动开发最容易翻车的地方就是模块之间互相直接访问内部数据最后改一个功能牵一发动全身。这里用struct npr2_port作为共享上下文每个端口一个实例tty 和 net 都持有它的指针但各自只改自己负责的字段。2.3 端口对象与模块参数的数据结构整个驱动的心脏是端口对象它把 tty 端口、socket、缓冲区三样东西绑在一起。看看npr2.h里核心结构体的典型定义#define NPR2_MAX_PORTS 32 #define NPR2_TX_BUFSIZE 4096 struct npr2_port { struct tty_port port; /* tty 子系统端口对象 */ struct socket *sock; /* 到 NPort 的 TCP 连接 */ struct task_struct *rx_task; /* 内核收包线程 */ spinlock_t lock; /* 保护缓冲区与计数字段 */ wait_queue_head_t wq; /* 发送线程等待队列 */ unsigned char ip[16]; /* NPort 设备 IP */ unsigned short net_port; /* NPort 监听端口 */ unsigned int baud; /* 串口波特率 */ unsigned char data_bits; /* 数据位 5/6/7/8 */ unsigned char parity; /* 校验位 */ unsigned char stop_bits; /* 停止位 */ unsigned int rx_bytes; /* 统计接收字节数 */ unsigned int tx_bytes; /* 统计发送字节数 */ unsigned int link_state; /* 链路状态 0/1 */ }; static struct npr2_port *npr2_ports[NPR2_MAX_PORTS];struct tty_port是内嵌对象不是指针这一点很关键。老式 tty 驱动经常自己维护一堆引用计数和互斥锁而新内核建议把端口状态交给tty_port管理open/close 的竞态它会帮你兜底。rx_task是内核线程指针因为 socket 收数据是阻塞的不能放在软中断或者工作队列里长期占用。link_state是给上层诊断用的后面二次开发加统计接口时直接读它。模块参数加载方式是这个驱动的特色RealTTY 方案通常不用设备树或配置文件而是靠insmod时传参一次性把所有端口的连接信息传给驱动static unsigned int npr2_count 1; module_param(npr2_count, uint, 0444); static char *npr2_ip[NPR2_MAX_PORTS]; module_param_array(npr2_ip, charp, NULL, 0444); static int npr2_net_port[NPR2_MAX_PORTS] {4001}; module_param_array(npr2_net_port, int, NULL, 0444); static int npr2_baud[NPR2_MAX_PORTS] {115200}; module_param_array(npr2_baud, int, NULL, 0444);npr2_count决定注册多少个 tty 设备npr2_ip和npr2_net_port决定每个设备连接哪台 NPort 的哪个端口npr2_baud是默认串口速率。多端口场景下用逗号分隔npr2_ip192.168.0.10,192.168.0.11。需要特别注意的是module_param_array对 charp 类型只填第一个元素如果数组长度超过传入个数后面的元素保持默认值。我之前就吃过这个亏后面避坑章节详细讲。3. 核心代码拆解从模块加载到 open/write 的完整调用链3.1 模块入口与 tty_driver 注册驱动加载时要做的事情很直接分配端口对象、构造 tty 驱动实例、注册进内核。看npr2_main.c里模块初始化函数的典型写法static struct tty_driver *npr2_tty_driver; static int __init npr2_init(void) { int ret; ret npr2_alloc_ports(); if (ret) return ret; npr2_tty_driver tty_alloc_driver(npr2_count, TTY_DRIVER_REAL_RAW); if (IS_ERR(npr2_tty_driver)) return PTR_ERR(npr2_tty_driver); npr2_tty_driver-driver_name npreal2; npr2_tty_driver-name ttyNPR; npr2_tty_driver-major 240; npr2_tty_driver-minor_start 0; npr2_tty_driver-type TTY_DRIVER_TYPE_SERIAL; npr2_tty_driver-subtype SERIAL_TYPE_NORMAL; npr2_tty_driver-init_termios tty_std_termios; npr2_tty_driver-init_termios.c_cflag B115200 | CS8 | CREAD | HUPCL | CLOCAL; npr2_tty_driver-init_termios.c_ispeed 115200; npr2_tty_driver-init_termios.c_ospeed 115200; tty_set_operations(npr2_tty_driver, npr2_tty_ops); ret tty_register_driver(npr2_tty_driver); if (ret) { tty_driver_kref_put(npr2_tty_driver); return ret; } npr2_proc_init(); pr_info(npreal2: %u port(s) registered as ttyNPR0..ttyNPR%d\n, npr2_count, npr2_count - 1); return 0; } module_init(npr2_init);这个函数里有几个值得注意的参数。TTY_DRIVER_REAL_RAW标志告诉 tty 层这个驱动提供的是原始字节通道不要对它做行规程的缓冲处理否则数据会在 tty 层被拆成行、加上回显工控二进制帧直接就废了。driver-name设为ttyNPR设备节点就会自动命名为ttyNPR0、ttyNPR1这样。major 240是固定主设备号如果你机器上的 240 被占了改成 0 让内核动态分配也行但动态分配后 mknod 和 udev 规则都要跟着变我一般固定一个不冲突的号。init_termios里面B115200 | CS8 | CREAD | HUPCL | CLOCAL是串口驱动最常用的组合B115200 表示波特率常量CS8 是 8 位数据位CREAD 开启接收CLOCAL 表示忽略 modem 控制线HUPCL 是最后一个进程关闭设备时挂断连接。这段默认参数非常重要因为它决定了业务程序不调用 tcsetattr 直接读写时驱动工作在什么模式下。卸载函数对应做逆操作tty_unregister_driver、tty_driver_kref_put、释放端口顺序不能乱。内核里模块卸载时如果还有进程持有设备文件tty 层会返回 -EBUSY所以驱动里还要在 release 回调里把 socket 关掉、把收包线程停掉这套逻辑在npr2_tty_release里。3.2 open 时建立 TCP 链路与 termios 初始化业务程序open(/dev/ttyNPR0)时tty 子系统的 open 流程会一路调到驱动的 open 回调。这个时机也是建立 TCP 连接的最佳位置——只有应用真正要用串口的时候才去连设备而不是模块加载时就全部连一遍。不过要注意 open 是进程上下文可以睡眠所以可以放心在里面做 socket 连接static int npr2_open(struct tty_struct *tty, struct file *filp) { struct npr2_port *p; if (tty-index npr2_count) return -ENODEV; p npr2_ports[tty-index]; tty-driver_data p; if (!p-sock) { int ret npr2_net_connect(p); if (ret) { pr_err(npreal2: port %d connect failed, err%d\n, tty-index, ret); return ret; } } tty-termios.c_iflag ~(IXON | IXOFF | ICRNL | INLCR); tty-termios.c_lflag ~(ICANON | ECHO | ISIG); return 0; }tty-driver_data是 tty 层留给驱动挂私有数据的指针后面的 write、ioctl 回调全靠它把 tty 和端口对象关联起来。npr2_net_connect里面做的是标准内核 socket 流程sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP, p-sock)然后设置sk_sndtimeo和sk_rcvtimeo超时再kernel_connect。NPort 的串口服务器工作在 TCP Server 模式驱动这边是 Client 主动连它。open 回调里我特别喜欢做一件事就是强制把 termios 的输入标志和本地标志清掉。为什么要这样因为 tty 默认的行规程会把收到的0x0D转成0x0A会把 XON/XOFF 字符当成流控吞掉如果业务程序读写的是二进制协议这些转换会让数据帧永远对不齐。我在 open 里直接关掉 IXON/IXOFF/ICRNL/ICANON/ECHO相当于给每个应用默认开了 raw 模式省得他们每次都要自己写stty raw。3.3 写路径应用 write 到 socket 发送应用的write(fd, buf, len)经过 tty 层最终会落到驱动的写回调。这个回调要注意它运行在进程上下文可以睡眠所以可以直接做阻塞的kernel_sendmsg。但因为 TCP 发送不一定一次能发完必须循环发送完整包static ssize_t npr2_write(struct tty_struct *tty, const unsigned char *buf, size_t count) { struct npr2_port *p tty-driver_data; size_t sent 0; int ret; if (!p-sock || !p-link_state) return -EIO; while (sent count) { struct kvec iov { .iov_base (void *)(buf sent), .iov_len count - sent, }; ret kernel_sendmsg(p-sock, p-msg, iov, 1, count - sent); if (ret 0) { if (ret -ERESTARTSYS) break; return sent ? sent : ret; } sent ret; } p-tx_bytes sent; return sent; }kernel_sendmsg的返回值是实际发送的字节数可能小于请求长度。驱动必须把已发送的数量返回给 tty 层tty 层才能从写缓冲里裁剪掉这些字节否则应用会以为数据没写完下次重发造成重复。如果返回错误码也要原样上传用户态write会拿到 -1 和对应的 errno。这里有个小细节-ERESTARTSYS表示系统调用被信号打断tty 层会优雅地重启这次写操作所以我在这个错误码上只是 break不把它当成致命错误上报。这里没有引入发送线程因为写路径本身就是进程上下文直接在 tty 线程里做 send 就够了加了线程反而要面对唤醒和缓冲的竞态。3.4 读路径内核收包线程与 flip buffer 推送读方向就完全是另一套逻辑了。socket 收数据不能像写路径那样借用进程上下文——数据是 NPort 主动推过来的没有对应的应用进程在等着。所以驱动必须开一个内核线程常年阻塞在kernel_recvmsg上等数据。收到数据后要把它灌进 tty 子系统的 flip buffer再推给可能正在阻塞读的应用static int npr2_rx_thread(void *arg) { struct npr2_port *p (struct npr2_port *)arg; unsigned char buf[4096]; struct tty_struct *tty; while (!kthread_should_stop()) { struct kvec iov { .iov_base buf, .iov_len sizeof(buf), }; int len kernel_recvmsg(p-sock, p-msg, iov, 1, sizeof(buf), 0); if (len 0) { if (len -ERESTARTSYS) continue; npr2_net_break(p); break; } tty tty_port_tty_get(p-port); if (tty) { tty_insert_flip_string_fixed_flag(tty, buf, TTY_NORMAL, len); tty_flip_buffer_push(tty); tty_kref_put(tty); } p-rx_bytes len; } return 0; }tty_port_tty_get是拿当前打开这个端口的 tty 对象同时增加一次引用计数。这个引用必须配对tty_kref_put,否则端口被 close 时 tty 对象释放不掉设备文件会一直被占用。tty_insert_flip_string_fixed_flag是批量化插入数据的接口TTY_NORMAL表示这些字节都是正常数据而不是 break 或帧错误。插入完成后必须调用tty_flip_buffer_push它会把 flip buffer 里的数据推到行规程继而唤醒正在read阻塞的进程。这个过程要注意如果你在中断上下文push 必须用tty_flip_buffer_push的 atomic 版本我们是内核线程用普通版本没问题。npr2_net_break做的事情是把p-link_state置 0、关闭 socket、置空p-sock然后等待下次 open 时重新连接。串口设备断线后业务程序的 read 可能会永久阻塞所以有些版本的驱动会在断线时向 tty 发送挂断信号让应用感知到链路异常这属于可选的增强行为。4. 编译部署从源码到 /dev/ttyNPR0 的完整流程4.1 编译前的内核头文件准备拿到源码后先别急着 make先确认当前环境能不能编译内核模块。内核模块编译必须依赖当前内核的构建目录检查方法很简单uname -r ls -l /lib/modules/$(uname -r)/build如果/lib/modules/$(uname -r)/build不存在或者指向空目录说明没装内核头文件。Debian/Ubuntu 系装linux-headers-$(uname -r)RedHat 系装kernel-devel。这里经常有人栽跟头自己下了内核源码包PATH 也配了但 Makefile 里的 KERNELDIR 指向的是/lib/modules/$(shell uname -r)/build这个路径是软链接它必须指向与当前运行内核完全一致的构建树版本号差一个小版本都会导致 insmod 失败。4.2 Makefile 与内核模块编译驱动源码里自带的 Makefile 一般长这样obj-m指定要构建的模块多文件目标用-objs列出所有源文件obj-m : npreal2.o npreal2-objs : npr2_main.o npr2_tty.o npr2_net.o npr2_proc.o KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean注意 Makefile 里all和clean下面的命令行必须是 Tab 缩进不能用空格。然后直接执行make编译完成后当前目录会生成npreal2.ko这就是最终要加载的内核模块。编译过程中如果报错九成是头文件路径不对或内核源码版本与运行版本不一致先把make clean再做一遍别在旧 .o 文件上反复排查。4.3 模块参数与 insmod 加载单端口场景最简单加载命令把 NPort 的 IP、端口、波特率三个参数传进去sudo insmod npreal2.ko npr2_count1 \ npr2_ip192.168.0.10 \ npr2_net_port4001 \ npr2_baud115200多端口场景用逗号分隔每组参数一一对应sudo insmod npreal2.ko npr2_count2 \ npr2_ip192.168.0.10,192.168.0.11 \ npr2_net_port4001,4001 \ npr2_baud115200,9600加载成功后执行ls /dev/ttyNPR*应该能看到ttyNPR0和ttyNPR1没有的话先看 dmesgdmesg | tail -20insmod和modprobe的区别这里要提一句insmod不解析依赖、不读/etc/modprobe.d配置如果你要固定参数持久化加载应该把参数写进/etc/modprobe.d/npreal2.conf然后用modprobe npreal2。我一般调试期用 insmod上生产用 modprobe避免重启后设备节点不在了。4.4 udev 规则与基础验证模块加载后生成的设备节点默认属主是 root:root普通用户打不开。写一条 udev 规则固定权限创建/etc/udev/rules.d/99-npreal2.rulesKERNELttyNPR*, MODE0666如果要限制到特定用户组把MODE0666改成MODE0660 GROUPdialout然后把业务用户加入 dialout 组。改完执行udevadm control --reload-rules让它生效。第一次验证建议直接用stty配 raw 模式然后 echo 一下。NPort 串口侧如果做了 TX/RX 短接回环那么下面这条命令应该能收到自己发出去的数据stty -F /dev/ttyNPR0 115200 raw -echo echo hello /dev/ttyNPR0 timeout 1 cat /dev/ttyNPR0如果 cat 有输出说明链路是通的TCP 连接、tty 注册、读写路径都正常。如果没有输出先别怀疑驱动用nc或telnet直接连 NPort 的 IP 和端口看串口服务器本身是否正常转发。这套排查顺序能帮你快速定位是驱动问题还是网络设备问题。5. 排查手记加载失败、粘包与 termios 设不上的 5 个实战问题5.1 insmod 报 Exec format error现象insmod npreal2.ko提示Exec format errordmesg 里跟着一行version magic x.x.x should be y.y.y。原因编译用的内核头文件版本与当前运行内核不一致。最常见的是你下载的内核源码树和/lib/modules/$(uname -r)/build指向的不是同一套东西Makefile 里的 KERNELDIR 写死了某个旧路径或者编译机器和运行机器内核版本不同。解决先uname -r确认运行版本再确认/lib/modules/$(uname -r)/build存在且指向正确。如果是交叉编译场景Makefile 里 KERNELDIR 要显式指定目标机的内核构建目录不能依赖 SHELL 变量。然后make clean重编看 vermagic 是否一致。我吃过这个亏后来养成了编译前先ls -l /lib/modules/$(uname -r)/build看一眼目标的习惯。5.2 open 设备返回 -EIO 或应用卡死在 open现象设备节点存在但业务程序 open 报No such device or address或者 open 成功但 read 永远不返回dmesg 里有connect failed, err-113。原因open 回调里懒连接建立 TCP 连接失败了。-113是EHOSTUNREACH,常见于 IP 写错、网段不通、NPort 设备没开机。还有一种是 NPort 被配置成了 RFC2217 模式或 UDP 模式驱动拿裸 TCP 去连协议对不上连接建了也被断掉。解决先nc -vz IP port从服务器测 TCP 连通性通的话直接用nc IP port连上去看有没有串口数据回流。如果 nc 能通而驱动连不上检查模块参数里npr2_ip和npr2_net_port是不是真的传进去了cat /sys/module/npreal2/parameters/npr2_ip看一眼。NPort 的 Work mode 要设成 TCP ServerTCP alive timeout 配成一个合理的值别让半开连接挂在那。5.3 write_room 为 0应用数据写不出去现象业务程序write返回值一直是 0或者 tty 层的写缓冲永远满驱动 write 回调根本没被调用。原因驱动没有实现write_room回调或者实现里恒返回 0。tty 子系统通过write_room判断驱动还能吞下多少字节返回 0 它就认为没有空间直接暂停写入应用层表现为写不进去。解决实现write_room返回环形缓冲区的剩余空间static unsigned int npr2_write_room(struct tty_struct *tty) { struct npr2_port *p tty-driver_data; return NPR2_TX_BUFSIZE - npr2_tx_used(p); }同时保证在发送线程消费完数据后调用tty_wakeup(tty)唤醒等待写入的进程。这个回调不是可选优化是 tty 驱动必须实现的漏了就是写不动的玄学故障。入库前建议把所有 tty_operations 回调列个表逐一核对凡是串口驱动该有的 open/release/write/write_room/ioctl 一个都不能少。5.4 数据能通但第一字节丢失或乱码现象cat 设备能看到 NPort 那边发来的数据但开头几个字节是 0x00或者二进制帧里某些字节神秘消失。原因termios 默认的行规程正在做“好事”——把0x0D转成0x0A把 XON/XOFF 字符当流控吞掉ICRNL把回车当换行。如果业务程序没设置 raw 模式这些转换会破坏任何二进制协议。这不是驱动收发的 bug是 tty 层在中间做了手脚排查起来特别像玄学。解决open 回调里强制清除IXON | IXOFF | ICRNL | INLCR输入标志和ICANON | ECHO | ISIG本地标志把所有端口默认设为 raw 模式。验证的时候先stty -F /dev/ttyNPR0 raw再跑业务程序。我曾经在一个设备联网项目里被这个问题搞了整整一天线上数据帧怎么都对不齐最后发现是 termios 默认把0x03字符当成信号处理了从那以后我写串口驱动必做一件事open 时直接把 termios 刷成 raw绝不依赖应用自己去设置。5.5 多端口参数相互覆盖现象npr2_count2加载后两个 ttyNPR 设备连的都是同一台 NPort改第二个端口的参数第一个跟着变。原因module_param_array对charp数组的处理有坑。npr2_ip192.168.0.10,192.168.0.11这种写法只有加载时传了两个值数组才有两个元素如果你只传了一个 IP第二个元素是 NULL驱动里用strcpy或者strcmp时直接崩或者 fallback 到默认值两个设备就指向了同一个 IP。端口号数组也有类似问题只给一个4001第二个端口也默认 4001两台 NPort 就撞车了。解决驱动初始化时对每个端口的参数做收敛检查和默认值回填然后往/proc/npreal2输出一张端口参数表。加载时写全参数别省逗号sudo insmod npreal2.ko npr2_count2 \ npr2_ip192.168.0.10,192.168.0.11 \ npr2_net_port4001,4001 \ npr2_baud115200,9600加载完先cat /proc/npreal2对一遍端口数量和 IP确认没问题再起业务。6. 实战改造给驱动加一个动态改波特率与诊断统计的 ioctl很多工控场景里串口设备的波特率不是永远不变的上位机软件可能需要在运行中切换。RealTTY 驱动如果只靠模块参数定死波特率业务层就不得不重启驱动来改参数这在生产环境是不可接受的。比较好的方案是给驱动补两个 ioctl一个动态改波特率一个读链路统计。先定义用户态和驱动共享的协议头#define NPR2_MAGIC R #define NPR2_IOCSBAUD _IOW(NPR2_MAGIC, 1, int) #define NPR2_IOCGSTAT _IOR(NPR2_MAGIC, 2, struct npr2_stats) struct npr2_stats { __u32 rx_bytes; __u32 tx_bytes; __u32 rx_count; __u32 tx_count; __u32 link_state; __u32 dropped; };驱动侧在tty_operations里挂 ioctl 回调实现分发static int npr2_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned long arg) { struct npr2_port *p tty-driver_data; int baud; switch (cmd) { case NPR2_IOCSBAUD: if (copy_from_user(baud, (void __user *)arg, sizeof(baud))) return -EFAULT; return npr2_set_baud(p, baud); case NPR2_IOCGSTAT: { struct npr2_stats st { .rx_bytes p-rx_bytes, .tx_bytes p-tx_bytes, .link_state p-link_state, }; if (copy_to_user((void __user *)arg, st, sizeof(st))) return -EFAULT; return 0; } default: return -ENOIOCTLCMD; } }copy_from_user和copy_to_user是内核态和用户态传数据的标准接口不能用 memcpy。npr2_set_baud里先校验波特率是否在合法范围内合法就更新p-baud如果连接的 NPort 支持 RFC2217 协议还可以通过 socket 给设备发一条波特率切换指令让串口服务器侧同步切换。不支持的话就只能改本地参数实际波特率需要到 NPort 的 Web 管理页手动改。生产环境里的做法是优先用 RFC2217,实在不支持再说。改造完成后写一个几十行的用户态工具验证open 设备ioctl(fd, NPR2_IOCGSTAT, st)读统计ioctl(fd, NPR2_IOCSBAUD, baud)改波特率然后看/proc/npreal2里的状态是否同步变化。这比反复 insmod/rmmod 验证参数靠谱得多也让业务程序有了运行时调整的手段。另外提醒一句老内核里tty_operations的 ioctl 回调现在正逐渐移到tty_port_operations里如果你要移植到新内核先查当前内核版本对应的接口位置别照抄老代码。我早期给某边缘网关项目做驱动改造时因为没有提前留诊断接口现场调参只能靠重启大法来回折腾了好几轮——从那以后我每次写串口驱动第一个版本就先把统计计数和动态配置类的 ioctl 铺好调试手段永远比功能先到位希望帮到你。本文还有配套的精品资源点击获取