/dev 是内核通过 devtmpfs 动态生成的设备节点集合，本质是内核驱动接口而非数据容器；其文件无实际内容，open/read/write 等系统调用被重定向至对应驱动函数执行，与文件系统协作仅始于挂载动作。
/dev 目录不是挂载点，也不属于传统文件系统的一部分，而是内核通过 devtmpfs（内存中的临时文件系统）动态生成的设备节点集合。它与文件系统的交互不靠存储数据，而靠内核对“文件操作”的语义重定向——open、read、write、ioctl 等系统调用在 /dev 上触发的不是磁盘读写，而是驱动程序的函数执行。
设备文件本质是内核接口，不是数据容器
/dev 下的每个文件（如 /dev/sda、/dev/ttyS0）都对应一个内核中注册的设备驱动。它们没有实际内容，也没有磁盘块映射。内核为这些文件分配特殊 inode，其 i_mode 字段标明是字符设备（S_ISCHR）或块设备（S_ISBLK），并绑定预设的 file_operations 函数集：
- 字符设备：inode→f_op 指向 def_chr_fops，open 最终调用 chrdev_open，再根据主设备号查到驱动的 .open 方法
- 块设备：inode→f_op 指向 def_blk_fops，open 触发 bd_acquire 流程，关联到 block_device 和 gendisk 结构
- 所有 I/O 操作都不经过 VFS 的通用页缓存路径（除非驱动主动使用），而是直接进入驱动定义的逻辑
/dev 与真实文件系统的协作发生在挂载环节
块设备文件本身不存储文件系统，但它是挂载动作的起点。例如：
- 执行 mount /dev/sda1 /mnt 时，VFS 先调用 blkdev_open 打开 /dev/sda1，获取底层 block_device
- VFS 接着读取该设备前几个扇区，识别出 ext4 超级块，然后调用 ext4_mount 加载文件系统逻辑
- 此后对 /mnt 的读写，走的是 ext4 → page cache → block layer → 驱动 的完整栈，/dev/sda1 此时仅作为初始入口和底层载体
devtmpfs + udev 构成运行时设备视图
/dev 的存在依赖两个机制协同：
- devtmpfs：内核在启动早期自动挂载的内存文件系统，负责为已探测硬件创建基础设备节点（如 /dev/sda、/dev/tty0）
- udev：用户空间守护进程，监听内核 uevent，按规则（/etc/udev/rules.d/）设置权限、添加符号链接（如 /dev/disk/by-uuid/...）、触发脚本
- 两者分离职责：devtmpfs 提供“能用”，udev 提供“好用”；删掉 /dev 下文件不会影响驱动运行，重启或热插拔后自动恢复
与 /sys、/proc 的分工明确，不可替代
/dev 不处理配置和状态查询：
- /dev：专注数据流和控制指令传输（如 read() 拿摄像头帧、ioctl() 设置串口波特率）
- /sys：只读属性树，暴露设备拓扑、参数、开关（如 /sys/class/backlight/intel_backlight/brightness）
- /proc：进程与内核统计信息（如 /proc/diskstats），不参与设备 I/O
- 三者共存，共同支撑“一切皆文件”哲学，但角色严格区分
