在Rust中支持Linux内核开发

会议上达成了一些共识，即编写Rust包装器对于一些最常见和最关键的API来说是有意义的，但是手动包装每个内核API都是不可行的，也是不可取的。Thomas提到Google正在致力于自动生成C++代码的惯用绑定，并考虑内核是否可以做类似的事情，也许是建立在现有的稀疏注释之上，或者在现有的C中添加一些新的注释来指导绑定生成器。下一个讨论领域是架构支持。目前，唯一成熟的Rust实现是Rustc编译器，它通过LLVM实现代码。Linux内核支持多种架构，其中一些架构没有可用的LLVM后端。对于其他一些，LLVM后端存在，但是rustc还不支持该后端。演讲者想了解Fullarchitecture支持是否是在内核中启用Rust的拦路虎。有几个人说，在铁锈中实现驱动程序是可以接受的，而这些驱动程序无论如何都不会用在更晦涩的架构上。Triplett援引他在Debian项目中的经验，建议将Rust添加到内核中将有助于推动增加对Rust的架构支持。他提到将Rust软件引入Debian有助于激励利基架构的爱好者和用户改善对Rust的支持，他希望增加对内核的支持也会有类似的效果。特别是，他相信任何具有LLVM后端的架构都会很快在Rustc中得到支持。对话还讨论了替代Rust实现作为通向更广泛架构支持的路径。Mrustcproject是一个实验性的Rust编译器，它发出CCODE。使用mrustc可能会让Rust通过编译内核其余部分的Samec编译器进行编译。此外，Triplett提到了GCC对Rustfront End的一些兴趣和工作，这可能使Rust能够瞄准GCC支持的任何架构。这个项目还处于早期阶段，但它代表了另一种在未来缩小体系结构差距的方法。这一部分的结论有点不确定，但似乎没有强烈反对在不等待更广泛的体系结构支持的情况下支持RustDevice驱动程序的想法。Gaynor还就ABI的兼容性问题征求了意见，由于Rust(目前)是通过LLVM编译的，内核最常见的是用GCC构建的，将Rust代码链接到内核中可能意味着混合GCC和LLVM发出的代码。尽管LLVM的目标是与GCC兼容ABI，但由于担心这一策略会造成微妙的ABI不兼容的风险，也有一些阻力。演讲者想知道内核社区是否更愿意限制对用Clang构建的内核的Rust支持，以确保兼容性。Greg Kroah-Hartman确认，当前的内核规则是，只有在内核中的所有目标文件都是使用相同的编译器、使用相同的标志构建的情况下，才能保证兼容性。不过，他也表示愿意将LLVM构建的Rust对象链接到AGCC构建的内核中，只要这些对象是同时构建的，并且设置了适当的选项，并且得到的配置得到了充分的测试。除非出现实际问题，否则他认为在登陆之前没有必要施加任何额外的限制。Florian Wemer澄清说，ABI问题往往出现在语言的模糊角落-例如，按值返回包含位字段的结构-他预计ABI的核心、常用部分应该不会造成兼容性问题。特里普莱特强调，GCC和拉斯特之间的通话是例行公事，在用户空间中很普遍，所以从拉斯特那一边来说，他并不担心兼容性。听起来，这种担忧最终不应该成为将锈菌带入内核的障碍。会议结束时没有任何进一步的具体后续步骤，但总的来说，似乎对最终支持Rust模块的热情很高，对这种支持的广泛要求也越来越达成一致。下一大步很可能是当有人提议将一个真正的Rust驱动程序包含到内核中时。具体的用例和实现总是有助于使任何剩余的有争议的问题和设计决策变得清晰。你喜欢这篇文章吗？请接受我们的试用订阅优惠，以便能够看到更多类似的内容并参与讨论。