最近，人们讨论了一些减轻内核维护者负担的方法。显然，合并窗口期 是非常繁忙的时期，有些人希望提醒贡献者一些更可取的代码提交习惯。

有很多想法，Kevin Cernekee 以补丁的形式总结了这些想法，但一个关键的观点是，这些建议都不能被视为是金科玉律。尤其是 Linus Torvalds 和 Theodore Ts'o 指出，维护者都有自己做事的方式，任何通用规则都不能普遍地可靠地产生可重复的结果。

总的来说，正如 Kevin 所发布的那样，合并窗口期不是提交新补丁的好时机。合并窗口期是新内核版本发布后和第一个 -rc 版本发布前的时间。开发者要么应该避免在那段时间提交补丁，要么正如也讨论过的那样，他们至少不应该期望收到对其补丁的回复，并且如果第一个补丁似乎未被接受，他们应该避免在那段时间内第二次提交任何补丁。

Kevin 还发布了一个非常粗略的计算，开发者可以期望在官方内核中看到他们的代码的时间。如果他们在前四个 -rc 版本中提交代码，他们可以期望在下一个官方内核版本中看到他们的代码。如果他们在剩余的四个 -rc 版本中提交代码，他们可以期望在第二个随后的官方版本中看到它。Alan Cox 认为这个计算非常有价值，尽管 Linus 警告说这真的只是一个非常粗略的估计，并且高度依赖于任何给定维护者的特定补丁接受习惯。

Richard Weinberger 提出了一个安全改进建议，旨在针对那些以派生服务器为目标的攻击者，例如 httpd 和 sshd。显然，通过创建大量的派生，攻击者可以猜测每个派生内存分配中的代码位置。经过足够的尝试，它可能会找到关键代码的位置，并在父进程中启动 root shell。那将是非常糟糕的。

Richard 的想法是识别子进程是否由于致命错误而终止，并使未来的派生在执行前等待 30 秒。这将导致攻击花费更多时间，但往往不会给普通用户带来不便。

对这个想法有一些支持和一些反对意见。Pavel Machek 后来认为 Richard 的补丁只是试图以随机的方式减慢内核速度，希望它可能会有所帮助。但是 Kees Cook 和 Andy Lutomirski 都认为 Richard 的补丁是高度针对性的，不会不适当地延迟用户代码。

Richard 最初的想法是在探索 offset2lib 漏洞的复杂性时产生的，该漏洞详细说明了一种攻击代码识别内存中用户库位置的方法。一旦知道了这个位置，就有相对简单的方法来启动 root shell。因此，任何攻击者可以借此获得内存中代码位置知识的技术都必须被视为安全漏洞并立即修复。但是，并不总是清楚如何最好地阻止该信息被看到。

Arm 和 Arm64 项目正在经历一种成长的烦恼——两种架构上的 /proc/cpuinfo 文件之间存在一些不兼容性，这导致一些用户程序失去可移植性。

部分问题是，如果 Arm64 开发者想要保持可移植性，他们需要将 Arm 的所有 API 都合并到他们的代码中，尽管他们真的想放弃这些 API 而采用更好的 API。在当前情况下，/proc/cpuinfo 文件必须彼此保持一致，即使有代码依赖于它们之间的差异。

Russell King 对这种情况发表了一些看法，以警示故事的形式

As ARM64 wants to be compatible with ARM32 (in that it wants to be able to run ARM32 applications), ARM64 has to offer a compatible user API for everything that is a user API.

That means you have to generate an ARM32 compatible /proc/cpuinfo, ARM32 compatible hwcap information, ARM32 compatible signal structures, ARM32 compatible everything else. Which means you basically need to have a copy of the ARM32 core code in ARM64, even if you want a different native ARM64 user API.

This is exactly the reason why architectures like X86 decided it was silly having separated 32- and 64-bit, and why they went through a process of merging the two together. A lot of the code was identical, and a lot of the 32-bit-specific code was needed for 64-bit to provide the 32-bit API.

Right now, you're finding out this the hard way, and hitting these API problems in the process, and going "oh fsck" when you hit them—quite simply because you've backed yourselves into a corner over this. You have established a different ARM64 API because you didn't want the ARM32 legacy, but then you've found that you do need the ARM32 legacy. Now you're in the position of having to change the ARM64 API, possibly breaking ARM64 applications in the process.