面板驱动交给 BPF：DRM 维护者的提案，被当场追问「panic 时屏幕怎么办」；内核第一次能只编 IPv6

今天最值得读的一条是一次还没落地的架构尝试：DRM 维护者 Maxime Ripard 把 MIPI-DSI 面板的初始化序列做成 BPF 程序，让新屏支持不必再等内核补丁——发出来几小时， Neil Armstrong 和 Rob Herring 就分别从「早期启动显示」和「设备树绑定语义」两头发起了质疑。 另一条，内核第一次可以被编译成只带 IPv6：16 帖把 IPv4 从通用 socket 与传输层里解耦出来。

数据截至 09-29 06:23 北京，近 24h 各板块真实计数：net 717 · DRM 404 · mm 304 · media 257 · PCI 173 · fs 149 · Rust 88 · block 83 · LSM 54 · arch 37 · rt 33 · virtio 0。 今天量最大的仍是 net，但最重的一条在 DRM —— 而且是一条还没被接受的设计提案， 不是已合入的改动。

社区反应：发出来几小时内就分成了两派。 Neil Armstrong（Linaro）从早期启动切入：BPF 程序只能由用户态加载， 这就依赖了用户态行为——如果 initramfs 因故没起来， 就没有任何途径把错误显示出来；他同时提醒这「对于严肃应用来说太晚了， 除非我们先解决 bootloader 到 Linux 显示引擎的交接」。他还在绑定那帖里直接反对： 「我看不出这怎么能算有效的硬件描述，BPF 是软件实现，跟绑定无关」， 并担心把时序搬进 blob 会变成带闭源许可限制的专有二进制，为了一块屏更快点亮而付出降级代价 （原文）。 Laurent Pinchart 关心的也是同一件事：用户态可用之前，oops 的现场怎么打到屏幕上 （原文）。 HID-BPF 的作者 Benjamin Tissoires 则替这条路辩护：BPF 默认可以要求程序是 GPL 兼容的，闭源许可那条不成立；而且 BPF 目标文件比二进制 blob 容易反汇编得多，一个 pass 就近乎拿到源码 （原文）。 Rob Herring 针对绑定提出更基础的问题：既然一定要有面板专有的第一个 compatible， 那第二个兜底项意义何在？而且总该先挑一块已经在树里的面板转换过去做样例 （原文）。 他的机器人在同一线程里报出了 dt_binding_check 失败：示例节点与既有面板 schema 冲突、 compatible 过长、缺少必需属性。 这条线索的价值不在于结论，而在于它把一个问题摆上台面： 内核的「新硬件支持」是否必须绑定在「改内核」这一条路径上。