适合看看张雪峰

@james122333 #67

那请问你：你的代码是 hw 相关的，你怎么做能减少 hw 相关的代码，从而做到无需其他团队 /个人 /第三方配合，就可以做到一套代码跑在不同的硬件上

@james122333 #60 所以场景是不一样的。
你说的场景是云上的，用 vm 。Linux 内核怎么换都行，只要不出问题。但是 host 上的物理机系统就不一样了。

所以这就是两个市场：云上是 Ubuntu 占比高，host 上是 RHEL 。

@james122333 #50 你是从 vm 的角度来看的：统一的 virtio 硬件，不需要第三方的 ko 参与。

实际上与物理机关联，但凡 system 级别的开发，绕不过第三方提供的硬件与驱动。
high level 的代码可以做抽象，可以做 portable ，可问题是使用的硬件，虽然功能相同，不同公司的甚至不同版本的，驱动、so 都有差别。没法做 portable

@amiwrong123 #8 right 准确地来讲这是被优化后的代码，如果禁止优化的话 O0 应该就不这样了（没测试，可以看看）


@amiwrong123 #10 是的。这个要查手册页才能确定，而且贼琐碎。

arm 的话，返回地址是 r13 还是 r12 。
这个要查手册页了，programming manual 有详细的介绍（ arm 的手册很多，要仔细找找，有个 guide 简述了上述过程

一部分硬件，一部分软件。

准确地说：
通用寄存是是软件行为，特定的寄存器是硬件行为。
比如函数调用是软件行为，中断异常的寄存器保存（ amd64 下的 rip 、返回地址）是硬件行为

@james122333 #44
bug 种类多了去了，只有想不到没有它做不到。

不是强制指定系统，是第三方内核模块厂商编译成二进制打包后，在商业 Linux 操作系统提供商指定的版本下（商业 Linux 操作系统会明确表示在特定的一系列版本上兼容什么，不兼容什么）进行一系列测试，测试完成后会表示对此版本进行兼容。

客户要的就是这种兼容性保证。

那么如果商业 Linux 操作系统提供商表示用了 A 版本与 B 版本是兼容的，该内核模块在 A 版本上没有问题但是在 B 版本上出现了问题，那就是操作系统提供商的 bug ，否则就是内核模块提供商。
这种二进制发型的机制明确了责任归属。

@james122333 #44
使用商业版本的 Linux 操作系统不就是买服务吗

#36
国产 Linux 系统不是重新 build 一遍，只要自己维护内核，那么保证 kabi 兼容性、cve 补丁回合就是最重要的任务。
难度不高，就是繁琐。

@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 的版本。