同一份 Linux，为什么装进车里就长成了另一个物种

事情是这样的。前几天跟一个同事一起散步，他说为什么不能直接买一个平板放到中控台，当中控屏用，及省心又省事。

所以最近研究了一下。

我的车机，冷启动三秒就亮屏了。而我桌面上那台配置好得多的电脑，按下电源键之后，要先黑屏愣神半分钟，才肯给我看桌面。

更离谱的是那台车机，夏天在暴晒过的车里，七十度的环境底下跑一整天照样不卡。我电脑开个游戏，风扇就开始嚎。

然后我想起来，它们都叫 Linux 啊。？？？

同一个东西，凭什么在车上能秒启、扛高温、跑几万公里不死机，在电脑上就娇气成这样。

那天我把这个问题拆开看了一遍。看完之后我发现，车规 Linux 和桌面 Linux 虽然共用着同一份内核源码，但它们其实是被两套完全不同的假设浇灌出来的两个物种。

先说得最直白的那个不同。电脑上的 Linux 是装出来的，车上的 Linux 是减出来的。

你想想看 Ubuntu 的逻辑是什么。它假设什么都有可能发生，你可能插网卡，可能插显卡，可能插打印机，可能插一个十年前的 U 盘。所以它预装了成千上万个包，带着一堆你这辈子都用不到的驱动，开机的时候先把这份家当全部点一遍名。

光点名，就要十几秒。

车载 Linux 是反着来的。它是拿内核源码，跑一遍 menuconfig，把这块板子上永远不可能用到的东西全部勾掉，然后编译成一个只属于这款车的固件。

砍掉的东西换来三样收益。启动更快，内存更省，还有一样平时特别容易被忽略，攻击面更小。

一个系统里跑的代码越少，能被攻破的地方就越少。这在车上不是性能问题，是安全问题。

所以你看，车机三秒开机从来不是因为工程师把 Linux 优化得有多神，而是因为它根本就没装那些东西。

它不是一个更快的 Ubuntu，它是一棵被修剪过的树。

第二个不同，是我觉得最性感的一层。

桌面要的是平均快，车上要的是最坏情况也不能慢。

桌面 Linux 的调度器叫 CFS，完全公平调度，Completely Fair Scheduler。它的目标是把 CPU 时间尽量公平地分给每一个想干活的进程，让整体吞吐最大。某个任务晚了几毫秒，没人在乎，你真感觉不到。

车不行。仪表盘要每十几毫秒刷一帧，方向盘转过去到屏幕上的指针动起来，中间不能出现一个你等等我先处理下别的。

这里的关键词叫确定性。不是平均有多快，是最坏能有多慢。

一个任务如果平均一毫秒、偶尔蹦到两百毫秒，在电脑上毫无问题，在车上就是事故。

所以车规 Linux 要打 PREEMPT_RT 补丁，把内核里那些关掉中断、谁也别来打扰我的临界区尽量敲碎，让高优先级任务随时能抢占进来。关键任务走 SCHED_FIFO 或者 SCHED_RR，也就是实时调度策略，谁优先级高谁先跑，不讲公平。

这块有个坑我得说一下，很多人会踩。

Linux 就算打了实时补丁，它也只是软实时，不是硬实时。

真正的硬实时那半边，车上通常交给 QNX 那种微内核 RTOS 去做。所以你在车上看到的典型形态是，仪表和安全相关的部分跑 QNX，中控和娱乐的部分跑 Linux，两套系统在同一颗芯片上和平共处。

Linux 在车上从来不负责顶最硬的那根钢筋。

第三个不同，是我觉得最能体现工程师智慧的一层。

电脑有 BIOS 帮它认硬件，车上的板子什么都没有，只能靠一张户口本。

你在电脑上换块显卡，插上去，开机它就认了。因为主板上的 BIOS 或者 UEFI 会在启动的时候，主动把装了哪些硬件告诉操作系统，插拔也支持，热插拔也支持。

可你把一颗裸的 SoC 焊在一块车规板子上，它什么都不知道。它不知道 CAN 控制器挂在 0x31000000 这个地址上，不知道某个引脚的中断号是多少，不知道这块板子上到底有几路 I2C。

那内核是怎么知道的。

靠设备树。

一张描述这块板子上有什么硬件的文件，文本格式叫 dts，用工具编译成二进制叫 dtb，内核启动的时候读它。

它干三件事，告诉内核有什么硬件，告诉内核这些硬件怎么用，中断号时钟引脚怎么配，还告诉驱动怎么匹配，设备节点里写一个 compatible 属性，驱动里写一个 of_match_table，两边对上号，驱动就认领这个设备。

这件事的价值在哪。

改硬件，只改 dts，重新编译，不用动内核代码。

这就是硬件和软件解耦。一款车换了供应商、换了料号、换了传感器型号，软件那边可能一行都不用改。这在车上是个救命的设计，因为一款车从立项到停产，硬件改版是家常便饭。

说到这我得插一句，前面三个不同全都在讲内核里的事，但车规 Linux 真正让我觉得好玩的地方，反而不在内核里。

在一颗芯片上，Linux 常常只是租客之一。

这个词叫 Hypervisor，虚拟机监控器。车载上主流是 Type-1，直接跑在硬件上，跟你电脑上装在 Windows 里的那种 VMware 完全不是一回事。

它把 CPU 核心、内存、GPU、屏幕切开，分给不同的虚拟机。安全域拿独占的核心和内存，娱乐域拿剩下那部分算力。

切开的目的是隔离。

Android 那边崩了，重启就好，仪表这边毫秒级照样显示，眼皮都不抬一下。

这句话我特别想记住，娱乐可以坏，安全不能坏。

这八个字基本上就是整个车载软件架构的最高纲领。你后面看到的所有那些看起来过度设计的做法，都能从这句话推导出来。

写到这里，其实技术层面的事就讲完了。但我一直觉得，真正把车规和消费电子分开的那条线，压根不在技术里。

技术外面还包着一层东西，那层东西不产生任何功能，但过不了就上不了车。

我把它叫运行契约。

生命周期上，桌面的发行版两三年一个大版本，旧系统停更了，重装就行，反正你的数据都在云上。车载平台要跟着整车一起活十到十五年，这期间还得能修能升。

认证上，桌面上什么都不要。车上的芯片要过 AEC-Q100，开发流程要走 ISO 26262，软件过程要过 ASPICE。这些东西一个功能都不给你，纯成本。但不过，你就只能看着订单飞走。

更新方式上，电脑 apt upgrade 挂了，大不了重装。车上没有重装这个选项。所以要做 A/B 双分区，原子更新，新版本在另一个分区偷偷装好，验证没问题再切过去，出事了能一键回滚回上一版。

最后是失效后果。

电脑蓝屏，损失的是一个下午的心情。

车蓝屏，损失的可能是一条人命。

你把这四条摆在一起看，就会发现前面那些技术动作全都有了解释。为什么做减法，因为攻击面要小。为什么要确定性，因为人命关天。为什么要设备树，因为十五年里硬件要换好几轮。为什么要双分区回滚，因为车上没有重启一下试试这个奢侈的选项。

车规不是一个技术名词，它是一整套约束。做减法、加实时、用设备树描述硬件，都是这套约束逼出来的动作。

我后来还想到一个特别贴切的类比，F1 赛车和家用车。

两台车都有方向盘，都有刹车，都有发动机，热力学原理一模一样。但 F1 的每一个零件都是为极限工况单独定制的，刹车盘要能在几秒内从一千度降下来，发动机要撑住两万转，车重精确到克。家用车不需要这些，家用车需要的是便宜、耐用、能装、冬天能一把打着火。

同一个内燃机原理，被两套需求塑造出了两个完全不同的东西。

Linux 也是这样。

同一份内核源码，放在桌面上长成 Ubuntu，放在车里长成一套跟整车同寿命、能扛七十度、坏了不许蓝屏的定制系统。

再往上想一层，我觉得这甚至不是软件的事。

这是所有工程共同的宿命。形态从来不是原理决定的，是约束决定的。

你给它什么约束，它就长成什么样子。反过来也成立，你想知道一个东西为什么长成这样，别去读它的原理，去读它挨过的约束。

所以回到最开始那个问题。

车机三秒开机，不是因为它更快，是因为它更少。

下次要是有人跟你说，车机不就是个 Linux 电脑吗，你可以告诉他，内核确实可能是同一份，但那已经是两个东西了。

一个的假设是，通用、尽力而为、可以重启。

一个的假设是，确定、隔离、十年不能死。

同一份源码，两套假设，两个物种。