有人说坐着提肛提了一年，得前列腺炎了。。。

不错呀，搞得我也想尝试了

树莓派小车。远程操控+视频传输+图像识别。

@PTLin 打错了，不是栈上指针，是分配内存所得到的指针。

@iceheart 你可以去看看 rust for linux 的代码，rust 的抽象程度也就是 better c 的程度，就比如栈上指针的 box ，rust for linux 分成了三个类型，分别是 kmalloc 的 KBox ，kvmalloc 的 KVBox 和 vmalloc 的 VBox 。
你要说的 raii 的话，rust 也有一堆办法可以让一个类型避免超出作用域被析构，甚至直接调用 kmalloc 系列用和 c 一样的原始指针也可以。
我就这么说把，rust 的代码就算内核里的 c 开发者没学过 rust 也能完全搞明白代码逻辑，根本没有 cpp 里那么多 implicit 的东西，也没有 cpp 那么多的黑魔法，起码 review 的时候很直观。

@iseki 当然是写 dma 抽象的人来修，而且 rust 侧的很多 wrapper 本身都不是太复杂，就比如这次抽象的 dma_alloc_attrs 本身逻辑简单，就是可以附加不同属性的分配 dma 内存，就算由 break 了估计最多一小时就能完事。

后面的故事我已经想好了。
下一集：Christoph Hellwig 不满 linus ，fuck rust ，对 dma api 进行 breaking change ，煽动起社区厌恶 rust 的人一起来挑战 linus 权威。
linus 随之反抗，将 Christoph Hellwig 从 dma mapping helpers 除名。
借此一战 Hellwig 成功吸引到一批追随者，随之对内核进行 fork ，剔除了 rust 。
历史上称此次事件为<<<RUST, F*** You! , Linux fork PANIC!!!>>>
（狗头）

@PTLin 当然不是说 2 3 这些变量 setjmp 前后一定就在寄存器里，也可能一开始由寄存器表示，随着指令的执行因为某些原因被压入到了栈中，但是最后当使用的时候总是会正确的从栈中复原出来。

@heiher 感谢回答，我也是太久没接触过调用规范了，一时间有点懵了。
总结下，这分为三种情况
1 变量在 setjmp 后从栈读取。
2 变量在 setjmp 前后都是从保留寄存器（ callee saved ）读取。
3 变量在 setjmp 前后都是从临时寄存器（ caller saved ）读取。
第一种情况自然万事大吉。
第二种情况，setjmp 会保存 callee saved ，longjmp 会恢复 callee saved ，所以寄存器值始终正确。
第三种情况，在 call setjmp 前就会把变量所在的 caller saved 寄存器压栈，而在 setjmp/longjmp 返回后会把变量代表的 caller saved 寄存器弹出。所以寄存器值始终正确。

@heiher 这两天把你的协程库看了个大概。hev_task_execute 切换栈，hev_task_executer 和 hev_task_system_schedule 里 setjmp 前后对栈上 task/ctx 变量的维护和用其实现的协程切换确实很有意思。
不过我有个疑问，比如 x86 下 hev_task_executer 中，setjmp/longjmp 只会保存和恢复保留寄存器以及 rsp rip ，怎么保证 longjmp 切换上下文后，hev_task_executer 后续读取 task 变量一定从栈上读的，确保 task 变量不会被优化成寄存器变量呢？

@heiher 老哥你这个挺牛逼呀，自己手撸了协程库，socks5 库，服务器库，代理库和隧道库。

可惜 v2 没有删帖功能，题主要被教训两三天了。

哪吒这种面向院线的合家欢电影，画面 >>> 人物 > 爆点 > 剧情。

关键点就错了，问题说到底还是软件工程和政治问题，是一个超大型项目怎么引入第二语言或者一个重大变更并且协调开发者的问题，就更不用说 Linux 这种非中心化分布式开发的大型项目了。
除非一个大功能你能一个人搞定开发，调试，后续 breaking change 追踪更改。不然一但一堆人协调起来，一个人不接受就能让你一直卡在那。

uu 远程真的行

@hxndg 你说的对呀，本来就是所谓内存安全的语言也未必开发出整体逻辑安全的软件呀，这个不是共识吗，rust 又不是你用了就没 bug 了，只是通过语法消除一点内存方面的问题。

@hxndg 不是取代，是一直都有加入第二门稍微现代一点的语言到内核里建议，c++ for linux 的设想都十多年了，并且都有人写出 patchset 了，最后没被接受，最后不了了之了。
rust 所谓的内存安全其实不包含内存泄漏，而且现在的”内存泄漏“很大可能是是 glibc 分配器的问题，很多 rust 用 tokio 的程序换成 mimalloc 会好很多。并且所谓的安全其实反倒不是太重要，开发体验的提升才重要，毕竟 c 这个老古董，懂得都懂了，内核里现在都开始引入类似 go 里面 defer 的机制了。
并且这次吵起来中的人里就有维护 macbook 的那个 linux 发行版的人，因为那个内核里图形驱动就是 rust 写的，这个项目虽然不完善，现代的开发体验本身就是收益。
最后 rust 现在只是 kernel api 的抽象，最多只能用来写内核模块，短期内都不会出现 rust 写核心部件的情况。

每次都是想留点胡子，觉得更男人点，然后几天过去看着镜子感觉好邋遢，就又挂掉了

说实话，想要了解这次的冲突，起码要大概会点内核，明白大概的子系统，要很熟悉 rust ，并且看过 rust for linux 是怎么做抽象的和现在的项目进程才能说出点正常的评论。
不然就会犯以为现在 rust 重写了 Linux ，或者核心部分由 rust 编写了的错误。
实际上现在 rust 也就能写写驱动，做对 c 语言 api 的抽象，并且只抽象出来了非常小的一部分内核功能，这次的焦点 dma 的抽象都没有，离什么 rust 重写内核还差了十几年，而且 Linux 现在本身根本没有哪个部分是 rust 开发的。