V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  feather12315  ›  全部回复第 9 页 / 共 102 页
回复总数  2023
1 ... 5  6  7  8  9  10  11  12  13  14 ... 102  
manager 还是 Roger 吗
296 天前
回复了 ahill 创建的主题 程序员 资深程序员的晋升瓶颈
有了 ChatGPT ,junior 5 天的也可以一天完成。

除非资深干的是烧脑子的工作(比如 case by case 分析的问题),或者是讲故事,不然使用了 chatgpt 后,junior 跟资深没有区别。
299 天前
回复了 kuma42710 创建的主题 职场话题 核电工作前景怎么样?
求稳定的话可以去,这地方是贼稳定,就是规矩多。
适合看看张雪峰
@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 兼容性绝对搞死人。
1 ... 5  6  7  8  9  10  11  12  13  14 ... 102  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   987 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 43ms · UTC 22:28 · PVG 06:28 · LAX 15:28 · JFK 18:28
Developed with CodeLauncher
♥ Do have faith in what you're doing.