📚 课程目录第3章字符设备与网络设备对比

字符设备与网络设备对比：理解网络设备驱动与字符设备驱动的差异、网络设备驱动的核心接口（ndo_*）、设备模型（device/driver）基础

在Linux驱动开发体系中，字符设备驱动与网络设备驱动是两条截然不同的技术路径。字符设备以“文件”为抽象核心，通过open/read/write/ioctl等系统调用与用户空间交互；而网络设备则以“数据包”为处理单元，通过sk_buff、NAPI、ndo_*回调等机制实现数据收发。理解两者的本质差异，是掌握网络设备驱动开发的前提。本章将从设备模型基础出发，系统对比两类驱动的设计哲学、接口规范与数据流路径，并深入剖析网络设备驱动的核心接口ndo_*。

核心原理：两类驱动的设计哲学与数据路径差异

字符设备驱动与网络设备驱动的根本差异，源于它们对“数据”的不同理解。字符设备将硬件视为一个可读写的“文件”，数据以字节流或结构化缓冲区为单位，通过系统调用直接传递；网络设备则将硬件视为一个“数据包收发器”，数据以sk_buff（socket buffer）为基本载体，通过内核网络协议栈进行路由、分片、重组等处理。

从驱动开发者的视角看，最直观的差异体现在接口层：字符设备驱动需要实现struct file_operations中的read、write、ioctl等函数指针，而网络设备驱动需要实现struct net_device_ops中的ndo_open、ndo_start_xmit、ndo_stop等回调。前者面向“文件描述符”，后者面向“网络协议栈”。

数据路径的差异更为关键。字符设备的数据流是“用户空间 ↔ 驱动 ↔ 硬件”的直线路径，数据拷贝通常通过copy_to_user/copy_from_user完成；网络设备的数据流则是“用户空间 ↔ 协议栈 ↔ 驱动 ↔ 硬件”的环形路径，数据包在协议栈中经历路由、防火墙、Netfilter等处理，最终通过dev_queue_xmit发送，或通过netif_rx/NAPI接收。

  核心理解：字符设备驱动是“文件驱动”，网络设备驱动是“协议栈驱动”。前者关注数据内容的正确传递，后者关注数据包的时序、流量控制和协议栈交互。这一差异决定了驱动开发者在设计时的关注点完全不同。

判断方法：如何区分字符设备与网络设备驱动

在实际开发中，判断一个驱动属于哪种类型，可以从以下四个维度进行快速识别：

判断维度	字符设备驱动	网络设备驱动
设备节点	/dev/xxx（通过mknod或devtmpfs创建）	eth0、wlan0（由内核网络子系统分配）
注册函数	`cdev_add()` + `device_create()`	`register_netdev()` / `alloc_netdev()`
核心结构体	`struct cdev` + `struct file_operations`	`struct net_device` + `struct net_device_ops`
数据交互方式	系统调用（read/write/ioctl）	协议栈接口（sk_buff、NAPI、netif_*）

一个实用的判断技巧是：查看驱动中是否包含struct net_device_ops或ndo_前缀的函数。如果存在，则必然是网络设备驱动；如果包含struct file_operations且通过register_chrdev注册，则属于字符设备驱动。此外，网络设备驱动通常需要处理IRQ（中断）和NAPI调度，而字符设备驱动则更多依赖wait_queue或poll机制。

网络设备驱动的核心接口：ndo_* 回调详解

struct net_device_ops是网络设备驱动的灵魂，它定义了一组回调函数，由内核网络子系统在特定事件发生时调用。以下是开发中最常用的ndo_*接口及其职责：

ndo_open：设备激活入口。在此函数中，驱动应完成硬件初始化、申请DMA缓冲区、注册中断处理程序、启动NAPI调度等操作。对应命令ip link set eth0 up。
ndo_stop：设备关闭入口。释放资源、注销中断、停止NAPI，对应ip link set eth0 down。
ndo_start_xmit：数据包发送核心。协议栈将待发送的sk_buff传递给该函数，驱动负责将数据写入硬件发送队列（如DMA描述符），并在发送完成后释放sk_buff。该函数必须返回NETDEV_TX_OK或NETDEV_TX_BUSY。
ndo_get_stats64：获取设备统计信息（如收发字节数、错误计数），通过ifconfig或ip -s link查看。
ndo_set_mac_address：修改设备MAC地址，对应ip link set dev eth0 address XX:XX:XX:XX:XX:XX。
ndo_do_ioctl：处理用户空间的SIOCDEVPRIVATE等私有ioctl命令，用于扩展驱动特有功能。
ndo_change_mtu：修改MTU（最大传输单元），驱动需验证新MTU是否在硬件支持范围内。
ndo_tx_timeout：发送超时处理。当硬件发送队列长时间未完成时，内核调用此函数，驱动应进行复位或错误恢复。

// 典型网络设备驱动的 net_device_ops 定义示例
static const struct net_device_ops my_netdev_ops = {
    .ndo_open            = my_eth_open,
    .ndo_stop            = my_eth_stop,
    .ndo_start_xmit      = my_eth_start_xmit,
    .ndo_get_stats64     = my_eth_get_stats64,
    .ndo_set_mac_address = my_eth_set_mac,
    .ndo_change_mtu      = my_eth_change_mtu,
    .ndo_tx_timeout      = my_eth_tx_timeout,
    .ndo_do_ioctl        = my_eth_ioctl,
};

经验提醒：ndo_start_xmit运行在软中断上下文（或持有锁），不能睡眠。如果硬件发送队列已满，应返回NETDEV_TX_BUSY并停止发送队列（netif_stop_queue），待硬件完成中断后通过netif_wake_queue恢复。

设备模型基础：device/driver/bus 的协作机制

Linux设备模型的核心思想是“分离设备与驱动”。struct device描述硬件资源（寄存器地址、中断号、时钟、电源域），struct device_driver描述驱动逻辑（probe、remove、suspend、resume），struct bus_type负责将两者匹配。当总线（如platform_bus、PCI bus）检测到新设备时，会调用bus->match()函数，遍历已注册的驱动，寻找匹配项；匹配成功后，调用driver->probe()完成设备初始化。

对于网络设备驱动，probe()函数中通常需要完成以下步骤：

分配struct net_device：使用alloc_netdev()或alloc_etherdev()，并指定私有数据区大小（通过netdev_priv()访问）。
设置net_device_ops、ethtool_ops等回调。
初始化硬件：映射寄存器（ioremap）、申请中断、初始化DMA描述符环。
注册网络设备：调用register_netdev()，使设备对协议栈可见。

设备模型带来的最大好处是“驱动与设备解耦”。同一驱动可以匹配多个设备（通过of_match_table或id_table），设备的热插拔、电源管理、sysfs属性展示等均由内核统一管理。

案例拆解：从零编写一个虚拟网络设备驱动

为了更直观地理解网络设备驱动的核心接口，我们以一个虚拟以太网驱动为例，展示从设备分配到数据包发送的完整流程。该驱动不依赖真实硬件，而是通过内存缓冲区模拟数据收发，适合作为学习模板。

背景与约束：目标是在嵌入式Linux环境中创建一个虚拟网卡veth0，支持基本的ifconfig配置和ping通（通过loopback到自身）。约束条件：不涉及真实硬件寄存器，仅使用内核内存管理接口。

关键实现步骤：

// 1. 分配并初始化 net_device
struct net_device *ndev = alloc_etherdev(sizeof(struct my_priv));
strcpy(ndev->name, "veth%d");
ndev->netdev_ops = &my_netdev_ops;
ndev->ethtool_ops = &my_ethtool_ops;

// 2. 实现 ndo_open：分配发送/接收缓冲区
static int my_open(struct net_device *ndev) {
    netif_start_queue(ndev);
    return 0;
}

// 3. 实现 ndo_start_xmit：将数据包“发送”到接收队列
static netdev_tx_t my_start_xmit(struct sk_buff *skb, struct net_device *ndev) {
    struct my_priv *priv = netdev_priv(ndev);
    // 模拟发送：将skb数据拷贝到priv->tx_buffer
    skb_tx_error(skb);  // 实际驱动中应处理DMA映射
    dev_kfree_skb(skb);
    return NETDEV_TX_OK;
}

// 4. 注册设备
register_netdev(ndev);

结果与验证：加载驱动模块后，执行ip link set veth0 up，再执行ip addr add 192.168.1.1/24 dev veth0，最后ping 192.168.1.1应能通。通过ethtool veth0可查看驱动信息。

复盘经验：该案例展示了网络设备驱动的最小骨架。实际开发中，ndo_start_xmit需要处理DMA映射、发送完成中断、NAPI调度等复杂逻辑。初学者应先在虚拟设备上理解数据流，再过渡到真实硬件。

常见误区与总结复盘

风险提示：初学者常将字符设备的read/write思路套用到网络设备，试图在ndo_start_xmit中直接访问用户空间缓冲区。这是错误的——网络设备驱动只能处理内核空间的sk_buff，用户数据需通过协议栈的sendmsg路径进入内核。

另一个常见误区是混淆net_device与device的关系。struct net_device是网络子系统特有的设备抽象，它内嵌了一个struct device（通过dev成员），但两者不能互换。在设备模型中，网络设备驱动注册的是net_device，而字符设备驱动注册的是cdev + device。

总结本章要点：

字符设备驱动面向“文件”，网络设备驱动面向“数据包”，两者在接口、数据路径、注册方式上均有本质差异。
ndo_*回调是网络设备驱动的核心，其中ndo_start_xmit是最关键也最复杂的接口，必须遵循原子上下文和流控规则。
Linux设备模型通过bus匹配device与driver，网络设备驱动在probe()中完成net_device的分配、初始化和注册。
虚拟设备驱动是学习网络驱动的最佳起点，它屏蔽了硬件复杂性，让开发者专注于协议栈交互逻辑。