今日重点：📖 阅读——今天精读的是 Fault-Tolerant V4L2 的 RFC 封面信。 这封信值得读的原因不在术语，而在它的论证骨架： 一句立论 → 具体反例 → 用图演示失败 → 一句关键洞察 → 借鉴既有方案 → 主动坦白代价。 六步走完，维护者读完就知道该不该接。而且例子用的正是 GMSL 链路（imx219 + ds90ub953 + ds90ub960）。

📖 精读原文（真实邮件，逐字引用）

/ section
The V4L2 framework assumes that every entity of the camera pipeline is always present. This is a reasonable assumption for integrated cameras in laptops or phones. However, in automotive systems, cameras (e.g. rear-view or surround-view) can be damaged or disconnected. When the framework assumes all sensors are present, a single missing camera can prevent the entire pipeline from operating.
Also, the media graph should reflect the hardware topology, not just what's currently working. This way, userspace can distinguish "camera X is disconnected" from "camera X does not exist".

出处：Mattijs Korpershoek，[PATCH RFC 0/5] media: Fault-Tolerant V4L2， linux-media，10-01 20:55 北京。 原文

📖 拆解：六个论证动作

/ column
① 一句立论：先说清「框架假设了什么」 The V4L2 framework assumes that every entity ... is always present. 注意它没有一上来讲方案，而是先点出框架内建的那条假设。改动的正当性往往就藏在这里：不是「我想加功能」，而是「这条假设在某些场景下不成立」。
② 具体反例，并且当场让步 This is a reasonable assumption for integrated cameras in laptops or phones. 先承认这条假设在多数场景下是对的——笔记本、手机的一体式相机确实如此。However, in automotive systems 才转折。这个让步让后面的话更有分量：不是否定现有设计，是指出它的适用边界。
③ 把后果说到最重 a single missing camera can prevent the entire pipeline from operating. 一句话把代价讲透：不是「少一路能用」，是整条管线全废。原文后面还给了拓扑图证明——某颗 ds90ub953 probe 失败后，media-ctl 只剩 cdns_csi2rx -> ticsi2rx 一行，连另一颗正常工作的 imx219 也用不上了。
④ 一句关键洞察（全文最重要） the media graph should reflect the hardware topology, not just what's currently working. 这句是整封信的支点：图应该描述硬件怎么接的，而不是当前什么在work。由此推出那个漂亮的区分——userspace 要能分辨「相机 X 掉线了」和「相机 X 根本不存在」。
⑤ 借鉴而非新造 we chose to go for a simple solution inspired by DRM connectors. inspired by 是投稿信里的高频词：明确告诉维护者这套东西有先例，不是凭空发明。维护者最怕的就是「又一个自成一派的新接口」，这句话直接把这个顾虑消掉。
⑥ 主动坦白代价 The major downside however is that it will require to modify every driver since we're breaking away from the current pattern of not probing if the device isn't available. 自己先把最大的缺点说出来。这在 RFC 阶段尤其重要——与其等维护者发现「这要改所有驱动」然后反弹，不如自己标出来。

✨ 辅助彩蛋：术语卡

/ column

★ probe 的语义：从「设备在才 probe」到「设备不在也要 probe」

定义取自同一封 RFC

旧约定（原文指出的 pattern） the current pattern of not probing if the device isn't available——设备探测不到就不 probe，驱动直接失败返回。这是绝大多数驱动的默认写法，也是 V4L2「假设一切都在」的技术根源。
新要求（原文立的规矩） This mandates that the sensor driver can probe even when the device is not connected。驱动必须能在设备不接的情况下 probe 成功，把「设备不存在」变成一个可上报的运行时状态，而不是 probe 失败。
记忆钩子 probe 的成败语义变了：以前 probe 失败 = 设备不在；现在 probe 必须成功，设备在不在是之后由状态 ioctl + uevent 上报的事。你写 camera 驱动时如果还在 probe 里硬等设备响应，就属于旧约定。

✍️ 今日练习

/ column
✍️ 读原文里这句关键洞察：the media graph should reflect the hardware topology, not just what's currently working。请用英文回答两点：① 这句话立了什么规则？② 按这条规则，userspace 因此能做出什么区分（原文给了原话）？
💡 显示答案
参考作答（仿写示范，非原文）：① It sets the rule that the media graph describes how the hardware is wired, rather than which parts happen to be functional at the moment. ② With that rule in place, userspace can distinguish "camera X is disconnected" from "camera X does not exist" -- two situations that used to look identical, because a missing entity simply vanished from the graph.
📖 原文：Also, the media graph should reflect the hardware topology, not just what's currently working. This way, userspace can distinguish "camera X is disconnected" from "camera X does not exist".
📎 原文引用

每日一句：Name the assumption your change breaks, and say the cost out loud before anyone asks.

仿写示范