@james122333 #36
那你看 NVIDIA 的 dkms 模块能得到 NVIDIA 的商业支持吗？
就是 ko 出了任何问题都能找 NVIDIA 来 support 。

很多芯片厂商代码都是两套：一套是开源的，随便用；一套是给商业公司的。
给商业公司的代码，不少是二进制交付（而不是源码交付，看需求）。二进制交付的话，这个模块除了任何问题，都可以找厂家。


一个大型系统（比如存储系统），上下游团队很多，每个团队有自己的 release 。
以二进制交付的话，kabi 变更，任何一环变更了 kabi 导致的模块重新编译，都是不可承受的。
不以二进制交付，那就是源码交付。团队：我都源码交付了，模块遇到问题当然被交付方先处理了。 被交付方愿意吗？

@yyws2012 #16
内核不一样，你可以拉下来 kernel 的代码看看有没有结构体预留字段。

@james122333 #20
做成 dkms 也可以呀。可是用的结构体字段或者函数变更了，需要修改 dkms 代码才行。
第三方厂商愿意为你一个厂家适配吗？

但是第三方厂家愿意为 RedHat 、SuSE 、Ubuntu 企业版适配：因为他们签约合作协议。

为什么不做成 dkms ？因为要保证二进制一致性。这是 dkms 不具备的。
有时候编译器的改动都可能带来潜在的 bug ，以及：签名。dkms 编译的可不具备来自 server 厂商的签名：这需要用 server 厂商的构建系统构建。

kernel 只是一方面，还有 glibc 、systemd 之类的各种基础软件的兼容性：
发行版每个版本兼容性都稍微有点区别，企业版会给出 changelog ，社区版就不一定了。

我提一个企业版 Linux 才有的东西（或者说之前的 CentOS 才有的东西）：kernel 的 kabi 兼容性。

商业的 Linux 发行版，会在 Linux kernel 代码中的结构体预留很多字段，这些字段用于：
1. 新特性的 backport
2. bugfix

以及一个 kabi 白名单。


也就是说，尽管 kernel 的代码经过若干轮的 backport 、bugfix ，用掉了很多很多的结构体预留字段，只要第三方提供的内核模块使用的函数在白名单内，都会保证兼容性。

Debian 这种社区推动的，是不具备这些特性的。只有商业支持的 Linux kernel 才会有这些东西（比如 RHEL 、SuSE 企业版、Ubuntu 企业版，以及以前的 CentOS ）。

不使用第三方内核模块的话当然是用啥都行，使用第三方内核模块，随便使用发行版 kabi 兼容性绝对搞死人。

@anubu

当前的 OpenEuler 是 upsteam ，Euler OS 基于 OpenEuler, huawei cloud EulerOS 应该是 EulerOS ，华为云有自己的内部定制 OS ，是基于 EulerOS 的。

EulerOS 2.0 我不清楚。EulerOS 分界点在 2021 年，如果是 2021 年前出来的就跟 OpenEuler 没任何关系，2020 年的应该跟 CentOS 没关系，跟 OpenEuler 也没关系(OpenEuler 没出来呢），再往前推一个版本是基于 CentOS 的吧。

欧拉的构建系统用的是 suse 的 obs 。

2020 年以前内部的欧拉 OS 是 CentOS 改的，2020 年后（即开源出来的 openeuler ）完全是自己搞的，内部的欧拉 OS 21 年开始以 openeuler 为基础做了

欧拉自己从头搞的：spec 自己写的，自己从 upstream 直接引进版本、修 bug / cve ，跟其他发行版都没有关系。

suse 的欧拉版本应该是在 openeuler 的基础上重新打包的，麒麟也有基于 openeuler 的版本。

难道只有我等明年下半年吗？

我觉得明年下半年是个坎儿：
1. 明年下半年美国大选
2. 疫情后时代第二年
3. 俄乌战争第三年
4. 经济困难第三年

没有强有力的改革，我觉得要放烟花。

@coderluan #38 是的。生活没了盼头，就没有继续的动力了。

🐮

@qianfuyu #143 韩国不知道，日本恰恰相反：干啥都一样，政府的保障兜底，低欲望者的天堂

自己做自媒体呗

厉害

16 楼正解，属于叫 cacheline

我的 0 分

本质上也是 sriov ，NVIDIA 的卡依赖 GPU unloc