推荐下我自己用 rust 写的分流程序吧（仅支持分流，不含加密算法）： https://github.com/yuguorui/rfor

- 原生支持 IPv6 及其分流
- 针对 NAS 或 PT 环境，直连时支持源地址保留（即访问 IPv6 网站时如果是直连，那么会直接使用你设备的原有的 IPv6 地址，而不是路由器的）
- 零拷贝支持
- 自动设置 iptables 规则，退出时自动清除规则

@musi 利用 0day 这事情真的是记一辈子，不敢安装，真的是比我还了解我的手机。

@Nazz 也许你直接看 Gnome 的 doc 就 OK ？ fedora 和 Ubuntu 不一样，桌面应该很接近 upsteram 才对。

The hard way is usually the right way.

没有简单的方法，你需要理解当前的 feature 的工作原理，并评估当前 feature 的依赖依赖是否完备。
当依赖不完备是你需要考虑：是否需要引入新的 upstream patch ，还是用老的 API 实现 feature 所需要的逻辑等；
实现过程中可能还需要你不断迭代，直至你找齐所有的拼图。

邮件列表是一个参考，而不是一个答案。如何能根据快速的评估所需要的 patch 是你“不可替代”的要素之一。

@amiwrong123 你再看看上个回答？谜底就在谜面上。

愚以为直接存基址的话，在 32 和 64 之间就需要不同的大小来操作 ldt ，这个非常痛苦。
所以我理解 selector 的本质作用就是替换掉变长的地址宽度。

与其禁止 IPv6 ，不如让 IPv6 能正常处理。

可以试试： https://github.com/yuguorui/rfor

@ins0mn1a 你这里 post 出来的代码我还没看，但是大体上的逻辑是：
1. firmware 需要在启动时默认启用 IOMMU remapping ，然后后续的 DMA 请求就被默认禁止了；
2. 后面 firmware/OS 就可以根据需求更新 IOMMU 的 second-level page table 以允许 /吊销设备的 DMA 访问能力。

是否也就意味着该设备不会受到 IOMMU 的保护呢？
====================================
否

这里的细节很多，可以参考： https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf

说的更明白点，如果我是一个已经挂载在总线上的恶意设备，如果我不主动暴露 DMA 能力，没啥好方法探测。

如果你的假设是设备都是诚实的，倒是可以翻翻驱动，看看驱动分配时有没有用 DMA 相关的内存分配 API ，但是这个都只是启发式的。

设备支持不支持 DMA 和驱动没有必然联系。

一个设备有 DMA 控制器，能朝系统总线上写 DMA 相关的消息就可以进行 DMA 了（假设我不关心会不会把系统写挂）。以 PIC 为例，DMA 的过程实际就是写 TLP 包的过程，然后就可以通过 PCI 的路由逻辑路由到 DIMM 里了，这个过程和任何驱动有关吗？

@yuguorui96 额，后面的时间写反了，zlib 是快的那个哈。

写 1 亿没意思，连磁盘缓存都没打满……写个 10 亿吧
即使是随机数据，使用 zlib 这样的库也能极大的压缩数据

1e8, zlib vs raw, 810ms vs 310 ms
1e9, zlib vs raw, 11s vs 3.73s

https://gist.github.com/yuguorui/9700aa236dcb6e7072de282310d3b866

纯粹应付面试完全没必要，也确实无法深入。真是有兴趣可以写个 demo 驱动，解决问题才能深入结构。

也可能是是内核有内存泄露，我写过这样的 bug……

@bthulu 有的，云盒，云展，专有云。

数据上云场景： https://www.alibabacloud.com/help/zh/doc-detail/51655.htm

或者直接上传到 OSS 上。

@iBugOne 厉害，学到了。

附 docs： https://docs.python.org/3/library/ast.html#ast.literal_eval

@b00tyhunt3r 那你修改代码前要明确改动，与 merge 方同步再做他们允许的逻辑修改，而不是先自己闷头改。