这个内核函数可以更具可读性吗？（学术研究需要的想法！）答案

【问题标题】：Can this kernel function be more readable? (Ideas needed for an academic research!)这个内核函数可以更具可读性吗？（学术研究需要的想法！）
【发布时间】：2023-03-08 18:30:01
【问题描述】：

Following my previous question 关于超长函数背后的基本原理，我想提出一个关于我正在研究的piece of code 的具体问题。它是来自 Linux 内核的一个函数，它很长（412 行）并且很复杂（MCC index，共 133 行）。基本上，它是一个长而嵌套的 switch 语句

坦率地说，我想不出任何办法来改善这个烂摊子。调度表看起来既庞大又低效，任何子例程调用都需要数量惊人的参数才能覆盖足够大的代码段。

你觉得这个函数有什么方法可以改写成更易读的方式，而不损失效率吗？如果没有，您觉得代码是否可读？

不用说，我的研究中出现的任何答案都将得到充分肯定——无论是在这里还是在提交的论文中。

Link to the function in an online source browser

【问题讨论】：

你正在进行非常有趣的研究......
这个，以及你在这个主题上发表的任何其他帖子，都应该是社区 Wiki，恕我直言。
我认为内核代码与普通应用程序代码非常不同。尤其是实现了一个定义明确且易于理解的概念的代码，不需要更改或发展。

标签： linux-kernel switch-statement mcc

【解决方案1】：

我不认为该功能是一团糟。以前写得这么乱。

该功能是将微处理器制造商的表格代码转换为代码。这是非常低级的东西，为特定的中断或错误原因复制适当的硬件寄存器。在这种代码中，您通常无法触摸尚未由硬件填充的寄存器 - 这可能会导致总线错误。这可以防止使用更通用的代码（例如复制所有寄存器）。

我确实看到了一些代码重复。然而，在这个级别（在中断级别运行），速度更为重要。除非我知道提取的方法会被内联，否则我不会在公共代码上使用提取方法。

顺便说一句，当您在其中（内核）时，请务必捕获此代码的更改历史记录。我怀疑您会发现这里没有太多变化，因为它与硬件相关。这类代码随时间变化的性质与大多数用户模式代码所经历的变化性质完全不同。

这种情况会发生变化，例如，当实施新的整合 IO 芯片时。在那种情况下，更改很可能是复制粘贴并更改新副本，而不是修改现有代码以适应更改的寄存器。

【讨论】：

【解决方案2】：

太可怕了，恕我直言。显而易见的一阶修复是让 switch 中的每个 case 都成为对函数的调用。在有人开始抱怨效率之前，让我先说一个词——“内联”。

编辑：此代码是否是 Linux FPU 模拟器的一部分？如果是这样，这是一个非常古老的代码，它是让 linux 在没有 FPU 的 386 等英特尔芯片上工作的黑客。如果是的话，它可能不适合学者研究，除了历史学家！

【讨论】：

我能想到的唯一问题是需要传递的参数数量过长。
Neil：更多的话：它是 Linux。它可能需要建立在各种编译器上。除了做研究的人之外，也很可能没有人会看这段代码。
@Udi 因为它似乎与 FPU 有关，所以传递某种 FPU 结构似乎是有序的。

【解决方案3】：

这里有一种规律性，我怀疑对于领域专家来说这实际上感觉非常连贯。

还具有近距离的变化，可以立即进行目视检查。

我认为没有必要重构此代码。

【讨论】：

【解决方案4】：

我首先要为各种类定义常量。进入这段代码很冷，切换的目的是一个谜。如果切换是针对命名常量，我会有一个起点。

更新：您可以删除大约 70 行返回 MAJOR_0C_EXCP 的案例；只需让他们完成例行程序即可。由于这是内核代码，我会提到它可能存在一些性能问题，特别是如果案例顺序已经优化，但它至少会减少您需要处理的代码量。

【讨论】：

【解决方案5】：

我不太了解内核或重构它们的工作原理。

我想到的主要事情是采用该 switch 语句并将每个子步骤分解为一个单独的函数，其名称描述了该部分正在做什么。基本上，更具描述性的名称。

但是，我认为这不再优化功能。它只是将其分解为较小的功能，这些功能可能会有所帮助……我不知道。

这是我的 2 美分。

【讨论】：

函数调用开销会令人望而却步。这看起来像是中断处理程序的一部分 - 需要进入和退出。