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

@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 远程真的行