The genksyms tool has long been buried deeply within the kernel's build system; it is one of the two C-code parsers shipped with the kernel (the other being the horrifying kernel-doc script). It is a key part of how the kernel's module-loading infrastructure works. While genksyms has quietly done its job for decades, that period may soon be coming to an end. It would seem that genksyms is not up to the task of handling Rust code, so Sami Tolvanen is proposing a new tool to handle this task going forward.
genksyms 工具长期以来一直深埋在内核的构建系统中；它是随内核一起提供的两个 C 代码解析器之一（另一个是令人恐惧的 kernel-doc 脚本）。genksyms 是内核模块加载基础设施的关键组成部分。尽管 genksyms 数十年来一直默默地履行着职责，但这一时代可能即将结束。看起来 genksyms 无法胜任处理 Rust 代码的任务，因此 Sami Tolvanen 提议引入一个新的工具来替代它。
In the early days, the kernel only supported monolithic builds; there was no concept of loadable modules. That changed with the 0.99.15 release in early 1994, which added module support along with a number of other features. That release also was the beginning of the "code freeze" for the 1.0 release; Linus Torvalds said at the time:
在早期，内核只支持整体构建（monolithic builds）；当时还没有可加载模块的概念。这一情况在 1994 年初的 0.99.15 版本中发生了变化，该版本引入了模块支持以及其他若干功能。这个版本也标志着 Linux 1.0 发布的“代码冻结”阶段的开始；Linus Torvalds 当时表示：
Bumping the linux version number to 1.0 doesn't mean anything more than that: it's only a version number change. More explicitly, it does NOT mean that linux will become commercial (the copyright will remain as-is), nor does it mean that development stops here, and that 1.0 will be anything special in that respect.
将 Linux 的版本号提升到 1.0 仅仅是个数字上的变化，除此之外并没有更多含义。更明确地说，这并 不 意味着 Linux 将转向商业化（版权保持不变），也不意味着开发就此停止，或者说 1.0 版本会在这方面有任何特别之处。
Loadable modules at that time were tied to the specific version of the kernel they were built for. As Linux steadily became more commercial, though, there was an increase in interest in the ability to load a given binary module into multiple kernel versions. That interest was especially strong among those who were shipping out-of-tree modules and wanted those modules to work in as many kernels as possible.
当时，可加载模块必须对应于其构建时所用的特定内核版本。然而，随着 Linux 稳步迈向商业化，越来越多人希望能够将一个二进制模块加载到多个内核版本中。这种需求在发布 out-of-tree 模块（未并入主线的模块）的人群中尤为强烈，因为他们希望模块能在尽可能多的内核上正常工作。
Then, as is the case now, modules hooked into the rest of the kernel by way of exported symbols. Only symbols (corresponding to functions or variables) that have been explicitly exported are available to a loadable module, and modules can export symbols of their own as well. When a module is compiled to use a specific symbol, it naturally incorporates the type information associated with that symbol. Any change to a symbol (adding a parameter to a function prototype, for example, or rearranging the fields in a structure definition) will break modules that use those symbols, pos