【外评】为什么你的 Linux 内核错误报告可能毫无结果？

|

Linux 开发人员不修复已报告问题或完全忽略错误报告的常见原因

这些就是 Linux 内核开发人员忽视错误报告或对其反应寥寥的最常见原因：

有时，以下几个方面中的一个就是错误报告不能带来重大影响或修复的原因：

偶尔也会出现以下原因：

以下各节的文字将对上述各个方面进行更详细的解释。还介绍了一些相关要点，供希望更好地了解情况的人参考：

为什么？许多 Linux 内核开发人员都懒得调查使用此类内核报告的错误：他们怀疑问题可能并不存在于他们正在开发的代码中。这是很有可能的，因为 Linux 发行商或硬件供应商的内核通常都是从经过大量修改的源代码中构建的，使用的是附加驱动程序，或者从开发者的角度来看已经过时了。

怎么办？一种方法是向供应商报告问题。另一个办法是检查问题是否发生在从原始 Linux 内核源构建的真正新鲜的主线内核上（即所谓的 “vanilla kernel”）；如果发生了，请在报告中明确说明。

相关信息：请参阅 “您的内核显然是由修改过的 Linux 源代码构建的 “和 “您的内核显然加载了附加驱动程序”，了解为什么许多上游内核开发者都不能使用修改过的内核和附加驱动程序。要了解为什么任何超过三个月的内核系列通常都会有问题，请查看 “你使用了一个长期内核来报告一个错误，而这个错误并不是特定长期系列内的回归”；而 “你没有使用少于两周的主线内核 “则解释了为什么即使是来自最新稳定系列的最新内核版本也不够新鲜。

不过要注意的是，一些上游 Linux 内核开发者愿意调查 Arch Linux、Debian Sid、Fedora Linux 或 openSUSE Tumbleweed 等发行版的最新默认内核所报告的漏洞–至少只要它是基于最新的 Linux 稳定版系列发布的版本。这是因为这些发行版只做了很小的修改，一些开发者认为这已经足够接近上游版本了。但要注意的是，对于很多开发者来说，这些内核还不够好–因此他们可能会忽略或拒绝这类内核的报告。

为什么？许多 Linux 内核开发人员都懒得去研究这类内核的 bug：他们怀疑问题可能不会发生在他们正在处理的代码上，因为这些修改很有可能会导致问题。

怎么办？验证问题是否发生在从原始源代码构建的真正新鲜的主线内核上（即所谓的 “vanilla kernel”）；如果发生了，请在您的报告中明确说明。

相关信息：有些开发人员甚至不会仔细查看应用的修改，如果这些修改很小而且看起来无害的话，因为即使是这些修改也会导致各种各样的问题–通常甚至是在看起来完全无关的地方。

一位开发人员试图这样解释这种情况：

“想象一下，一本厚厚的书在开源许可下出版，需要注明出处。通过其他人出版的衍生产品，这本书变得非常有名，而这些衍生产品往往会修改部分文字，增加额外的章节，或者两者兼而有之。在这些修改和添加的内容中，自然会有一些错误。一些读者会向你，也就是归属的主要作者报告这些错误。一开始，您可能会足够重视检查任何报告的错误，并在文本中加以修正（如果有的话）。但由于其受欢迎程度和众多的衍生产品，如果发现许多报告的错误本来就不在你的文本中，这在某些时候就会变得很乏味。以至于你可能会停止调查任何关于修改过的作品中存在错误的报告，因为把时间花在更有意义的工作上似乎更好–尤其是当你已经有很多事情要做的时候”。

为什么？许多上游开发者根本不关心加载附加驱动程序（尤其是专有驱动程序）的内核中的 bug。从他们的角度来看，情况与构建时的修改类似（见上文）：问题很有可能根本不会在上游 Linux 内核中出现。

怎么办？验证问题是否发生在从原始源构建的真正新鲜的主线内核上（即所谓的 “vanilla kernel”）；如果发生了，请在您的报告中明确指出这一点。

相关信息：内核驱动程序一旦加载，就可以修改内核的方方面面–众所周知，一些专有附加驱动程序会利用这种潜力来获取利益。此外，专有驱动程序还会增加正确调试问题的难度，有时甚至是不可能的。

因此，当你的系统使用专有驱动程序（如 Nvidia 的驱动程序）时，几乎没有 Linux 内核开发者会费心去查看。对于许多开发者来说，独立于上游内核开发的 GPLv2 兼容驱动程序也是一个问题，比如独立开源开发者开发的驱动程序，或者那些公司单独发布或与其他软件捆绑发布的驱动程序（如 VirtualBox）。

为什么？内核开发人员让报告错误的人很难办，因为提交错误报告的正确位置取决于问题发生在内核的哪个位置；因此，在其他地方提交的报告可能根本无法送达开发人员。

bugzilla.kernel.org很容易出现后一种情况：它看似是一个报告错误的中心，但实际上并非如此。因此，许多在这里提交的报告从来没有被任何开发人员看到过；有相当多的开发人员甚至根本无法通过错误跟踪器找到这些报告。

只发送到邮件列表的错误报告通常也不会被相应的开发人员看到，尤其是只发送到 Linux 内核邮件列表 (LKML) 的错误报告。

怎么办？查阅 Linux 内核的 “报告问题 “文档，查看报告特定问题的适当目的地。然后在那里重新提交报告，但要确保添加一个小注释，并附上先前报告的链接。大多数情况下，您必须通过 CC 中的相应邮件列表向维护者发送新报告。在极少数情况下，bugzilla.kernel.org 是合适的地方；有时您必须将报告提交到外部跟踪器，如 gitlab.freedesktop.org。

为什么？很容易发生的情况是，每个人都认为您的报告应该由其他接收者之一来调查；尤其是在完全不清楚是哪个内核子系统出错的情况下，更有可能出现这种情况。

怎么办？给您的报告发送公开回复，在回复中直接询问子系统维护者最有可能出错的子系统（请根据您的猜测）。因此，在邮件的 “收件人：”字段中只写这些维护者，将其他人移至 “抄送：”字段。在邮件的开头，用维护者的名字向他们问好；然后友好地询问为什么没有收到回复，并就如何让事情继续进行征求意见。

为什么？普通的 Linux 内核开发者可能懒得仔细看，因为他们认为这是由稳定团队（也负责处理长期内核）来处理的事情；而后者同时也可能认为这是由普通的 Linux 内核开发者来处理的事情。到头来，就没人会去看你的报告了。

怎么办？基本上遵循 Linux 内核的 “报告问题 “文档。这将使你测试一个全新的主线内核，以确定你的错误是由常规开发人员还是稳定团队来处理的，或者可能是那些在特定的长期系列中永远不会被修复的问题之一。

相关信息：关于为什么没有人接收您的报告，请参阅 “大多数开发人员并不关心长期内核中的错误 “和 “向稳定团队报告错误往往只是走弯路”。

为什么？除非你报告的是稳定或长期内核系列中的回归问题，否则很可能没有开发人员会在意你的报告。从他们的角度来看，这个版本已经太老了：

  • 如果不是长期内核，要么已经不支持，要么随时会被打上 “生命周期结束”（EOL）的标签。
  • 如果是长期内核，您的报告就很有可能被漏掉；详情请参见上文 “您使用长期内核报告了一个错误，但该错误不是特定长期系列中的回归”。

怎么办？验证问题是否发生在从原始源构建的真正新鲜的主线内核上（即所谓的 “vanilla kernel”）；如果发生了，请在您的报告中明确说明这一点。

相关信息：每隔九到十周（例如两个多月）就会有新的主线版本发布；基于上一版本的稳定内核系列通常会在三到四周后被标记为 “寿命终止”。那时，所说的主线版本已经有大约三个月的历史了。

您的报告对其他人来说很难理解（太模糊、太混乱、链接太多……）

为什么？许多上游 Linux 内核开发人员似乎只花几秒钟就能决定他们收到的错误报告是否值得一读。即使他们仔细看了一遍，如果报告由于某种原因难以理解，他们有时也会很快转向其他工作。

有很多原因会导致报告属于这种情况。经常出现的原因有：描述过于简短、过于详细、过于含糊、过于混乱或没有自成一体（例如，只有通过链接或参考其他报告或讨论才能找到关键细节）。

怎么办？如果您怀疑这可能是您的报告被忽视的原因，请尝试发送一份新的、更好的报告–最好在提交之前让一两个朋友检查一下文本。在新报告中道歉，同时指出旧报告；这一点很重要，否则可能会让人觉得您在重复发送类似的报告，这会被认为是不礼貌的。

相关信息：请参阅 “Linux 内核范围内的开发者被视为志愿者，他们不欠你任何东西。”以了解为什么开发人员不需要查看他们收到的每一份错误报告。

还可以查看 Linux 内核的 “报告问题 “文档，其中有一节解释了如何创建一份好的报告。尤其是主题和第一段非常重要，因为许多开发人员不会继续阅读，除非这些内容能引起他们的兴趣。

为什么？如果报告或参与后续讨论的人员让开发人员感到恼火（无论原因是好是坏），开发人员可能会回避并忽略某个错误。

怎么办？过一段时间后，用更友好的语气再试一次。这样做时，请指出您的旧报告；这一点很重要，否则可能会让人觉得您在反复发送类似的报告，这将被认为是无礼的。必要时，也要为自己或他人在之前信息中的语气道歉。

相关信息：请参阅 “您的错误既不是回归也不是严重问题 “和 “Linux 内核范围内的开发者被视为志愿者，不欠您任何东西。”以了解为什么开发者可以随意忽略许多错误报告。

为什么？由于各种原因，这些报告经常被漏掉：

  • 最初的报告存在本文件所述的问题，因此没有得到重视；在报告的基础上添加一些内容往往无法挽回局面。
  • 最初的报告描述了一个症状相似或相同的问题，但最终却有完全不同的原因，或者需要特定的机器变通方法（”怪癖 “条目）；这样就很容易出现最终只解决了讨论中提出的部分或全部问题的情况。
  • 最初的报告被认为已经解决，开发人员也就不再关注它了。

怎么办？发送一份新报告，提及之前的报告并附上链接；后者很重要，否则可能会让人觉得你在重复发送类似的报告，这会被认为是不礼貌的。在之前的讨论中也简单说明一下并附上链接。

相关信息：只有当您非常确定现有的报告是关于完全相同的问题时，才可以将它们合并到一起。在所有其他情况下，请独立报告问题，同时注明并链接与您相似的报告；然后转到之前的报告，并回复一个简短的注释和您的新报告链接。这样，所有关注旧报告的人都会知道您的新报告，而那些对该主题最了解的人就可以掌握一切信息，迅速判断是相同的原因还是不同的原因。

为什么？报告中涉及的部分或所有问题可能都没有得到解决，因为开发人员可能忽略了报告中包含了一些与他们相关的内容。例如，当他们注意到关于其他开发人员必须处理的问题的描述时，他们可能就停止阅读了。或者他们很快就离开了，因为从他们的角度来看，报告很复杂，令人困惑–事实上，当一份报告涉及多个问题时，外人往往会遇到这种情况。

怎么办？发送新的报告，每期一份，除非它们之间的联系非常紧密。提及之前的报告并提供链接；后者很重要，否则会让人觉得你是在重复发送类似的报告，这会被认为是不礼貌的。在回复之前的报告时，也要简要说明并附上新报告的链接。

为什么？如果许多回复使得关于错误的讨论难以跟上，开发人员可能就会放弃。例如，当多个用户在一个主题中报告了类似的症状，而这些症状在表面上却有不同的无关原因时，就很容易出现这种情况；偏离主题、混乱、引用过多、评论过于详细或附件过多也会造成问题。这些问题尤其会让想要研究问题的新开发人员感到不快，因为他们可能没有耐心去查看一个错误的所有历史记录。

怎么办？视情况而定，这是个棘手的问题。最好向开发人员寻求建议。

有时，总结一下目前的状况就足以让讨论重新回到正轨。

有时，放弃旧的讨论并重新报告问题是唯一的出路–尤其是在多人加入报告以描述由完全不同的错误引起的类似症状时，更需要这样做来理清头绪。在重新报告时，请提及并链接之前的报告；还可以快速回复旧讨论，并附上简短说明和新报告链接，以便有关各方跟进。

为什么？目前还不清楚谁有义务调查此事：是相关代码的普通开发人员，还是稳定团队。

怎么办？检查主线是否也受到了影响，并在回复报告时分享这一信息；在这样做时，要明确指出负责的开发人员，否则他们可能会认为这是另一方需要处理的问题。

相关信息：请参阅 “大多数情况下，并不是稳定版团队必须主要修复长期内核中发现的错误”，了解为什么不同的开发人员会根据错误发生的位置来处理错误。

为什么？如果不使用 “git bisect “进行分割，就不清楚问题究竟是由内核的哪个部分引起的，因此可能没有开发人员会真正关心这个问题，仔细查看报告，这样一来，尽管 Linux 有 “不回归 “的规定，但这个问题可能永远都无法修复。

怎么办？分割回归。

相关信息：报告回归而不对其进行分割是没问题的，下文 “报告回归而不对其进行分割是完全没问题的 “对此有更详细的解释。但被联系的开发人员往往对原因一无所知。这时就需要进行分段，以确定哪些开发人员需要调查该问题。

相关章节：”Linux内核范围内的开发人员都是志愿者，他们不欠你任何东西”、”开发人员有时希望得到你的帮助 “和 “开发人员有时依赖于你的帮助”）。

为什么？有时，除非您提供额外的数据或调试和测试结果，否则开发人员无法提供帮助；有时，在您提供更多信息之前，他们可能没有动力提供帮助。在这两种情况下，如果您没有提供所需的信息或在此过程中需要大量的帮助，他们可能会拒绝。

怎么办？在试图最终提供所要求信息的同时，在跟进过程中道歉。或者询问如何真正做到所要求的。但要注意，过多的此类问题很快就会成为问题：因此，只要有可能，尽量利用搜索引擎或朋友帮助自己。

请参阅 “开发人员有时希望得到你的帮助”、”开发人员有时依赖于你的帮助”、”测试提议的修正符合你的利益，而且经常要求你这样做 “和 “Linux 内核范围内的开发人员被视为志愿者，他们不欠你任何东西。

为什么？你可能只是运气不好：内核开发人员需要修复回归和严重问题，但不需要解决每一个其他错误。有些错误最终没能解决。还有一些 Bug 是开发人员无法解决的，例如由于缺乏硬件文档。

怎么办？如果开发人员忽视了有关回归或严重错误的报告，请发送提醒，强调这方面的问题。对于其他问题，善意的提醒也是可以的（详见 “你只是运气不好”）；但如果对于这类错误，善意的提醒不起作用，那可能意味着你根本得不到任何帮助。

相关信息：请参阅 “Linux 内核范围内的开发者被视为不欠你任何东西的志愿者。”以了解为什么开发者不需要调查他们收到的每一份错误报告。Linux 内核的 “报告问题 “文档也详细描述了如果你没有得到任何帮助该怎么办。

为什么？像我们大多数人一样，内核开发人员偶尔也会在写作中忽略一些重要的东西，尤其是在这些方面并不显而易见的情况下。

怎么办？回复您的报告并强调它是关于回归的，例如调整主题并在正文中添加快速注释。记住要说明运行正常的最后一个版本和第一个损坏的版本；确保这两个版本都没有被修改或增强（请参阅 “你的内核显然是用修改过的 Linux 源构建的 “和 “你的内核显然加载了附加驱动程序”）。

为什么？有些开发人员甚至不查看稳定内核的错误报告：他们希望你查看当前的主线内核，因为错误可能已经在那里被修复了。

怎么办？验证问题是否发生在从原始源构建的真正新鲜的主线内核上（即所谓的 “vanilla kernel”）；如果发生了，请在您的报告中明确说明。

为什么？内核开发人员和我们大多数人一样：他们需要处理的事情很多，偶尔也会手忙脚乱–例如，由于休假或生病等原因，他们已经好几周没有靠近键盘了。这时，他们除了忽略最近推给他们的一些或所有事情之外，别无他法，而你的报告可能就是其中之一。

还有其他各种原因也可能导致你的运气不佳。例如，由于过滤器过于急切而导致邮件丢失。也有可能是某个与你同名同姓的人名声太坏，以至于被某些人列入了忽略名单。

怎么办？如果两三周都没有任何进展，在这种情况下，可以按照 Linux 内核 “报告问题 “文档的建议去做。这基本上可以归结为：检查你的报告是否因为本文档解释的原因而被忽略；如果没有，发送一封善意的提醒邮件，询问更新情况以及你是否能做些什么。

相关信息：由于 “你的错误既不是回归也不是严重问题 “和 “Linux 内核范围内的开发者被视为志愿者，他们不欠你任何东西。”.

在上游 Linux 内核开发的范围内，所有开发人员都被视为志愿者，因此显然可以自由决定把时间花在什么地方。

这是因为开发人员最终分为两类：

  • 公司、大学、政府机构和其他机构通过雇员、承包商、学生等自愿贡献力量。
  • 个人自愿贡献自己的时间。

除了他的声誉和对合并到主线中的内容的控制外，甚至连 Linus Torvalds 也没有办法让这些人做他想做的事。这使他能够激励，有时甚至强迫这些志愿者做他希望看到的事情–但即使对他来说，这也只能在一定程度上起作用，因为这些机构和个人可能会停止贡献，甚至分叉 Linux 内核。

原则上，即使是回归或严重的错误（如漏洞、数据丢失或硬件损坏）也是如此–但开发者或维护者会对这些问题进行调查，以避免坏名声，因为这会给他们今后的贡献带来麻烦，或者可能使他们丢掉官位。如果开发人员经常忽视像样的错误报告，这种情况也会发生–这也是开发人员通常在这方面提供帮助的原因之一。

您可能希望在报告回归时不对其进行分割，以避免在毫无价值的分割上花费时间和精力：

  • 开发人员可能已经知道了回归及其原因。
  • 有时，开发人员只需要适当的问题描述，就能通过有根据的猜测找出罪魁祸首。

因此，在初次报告中提出将问题一分为二就足够了，因为这样做有其重要意义：它将表明您愿意为修复回归所需的侦查工作尽一份力（请参阅下文 “开发人员有时希望得到您的帮助 “和 “开发人员有时依赖于您的帮助”）。但是，如果两三天后您还没有收到 “我们知道此事 “的回复，那么您就需要从分段开始；甚至可以先发制人，在发送报告后立即开始。

稳定团队在 Linux 内核开发过程中的固定方式导致了各种隐藏的、稍显不直观的方面。其中之一就是你不希望向常规开发人员报告长期内核中的错误，因为他们很有可能并不关心长期内核，从而忽略它。

这是因为普通开发者可以随意忽略稳定内核和长期内核，因为这些内核由稳定内核团队维护（见下文 “普通开发者可以随意忽略稳定内核和长期内核”）。有些开发者会在一定程度上帮助团队，但即使是这些开发者，通常也不会太在意长期内核中的错误报告：

  • 从他们的角度来看，很可能他们什么也做不了，因为你的错误可能已经在主线中修复了–可能是有意为之，也可能是其他改动的副产品。
  • 您的问题很有可能是由于稳定团队的不完整回传造成的，从开发人员的角度来看，他们应该修复这些问题。
  • 您的问题可能是一个已知的错误，在长期系列中永远不会被修复，因为回传修复被认为风险太大。

当然，你的问题也有可能在主线 Linux 中仍然存在。但对于开发者来说，快速检查通常很难，有时甚至是不可能的（请参阅 “开发者有时希望得到您的帮助”）；而且在四种可能结果中的三种情况下这样做对开发者来说可能是浪费时间，因此他们通常不会费心。

稳定团队在 Linux 内核开发过程中的固定方式导致了各种隐藏的、稍显不直观的方面。其中之一就是对于普通的内核开发者来说，参与稳定内核和长期内核的维护一直都是可选的。这种情况不太可能在短期内改变。

造成这种情况的大部分原因在于历史，因为早期的稳定内核和长期内核都是个别开发者在开发社区的边缘发起的。一些内核开发者喜欢这个想法，但即使是这些人中的大多数，最初也不愿意提供帮助。因此，启动这些系列的个人不得不在没有更广泛社区真正支持的情况下维护他们的内核系列。

随着时间的推移，当 kernel.org 的首页开始宣传稳定内核和长期内核，并成立 “稳定团队 “负责维护工作时，稳定内核和长期内核就变得更加正式了。因此，这些系列内核开始看起来像是整个社区的努力，但到目前为止，情况并非如此：它们仍然被认为是稳定团队的主要领域。目前，稳定团队只有两个人；支持这一想法并定期提供帮助的开发人员比最初要多得多，但许多人只是偶尔提供帮助，或者根本就不提供帮助。

这种情况从未在内核开发者社区中受到广泛质疑。除非核心内核开发者宣布必须参与某些或所有稳定的长期系列，否则这种情况很可能会一直持续下去。目前还没有任何迹象表明这种情况会很快发生。

您不希望向稳定版团队报告错误，除非是稳定版或长期系列中的回归。即便如此，将问题主要报告给常规开发人员可能更符合您的利益。

这是因为稳定版和长期内核中的绝大多数错误都必须由主线中的常规开发人员先修复；还有一些错误在旧版本中根本无法解决。如果您想了解原因，请参阅下面的 “大多数情况下，不是稳定版团队必须主要修复长期内核中发现的错误 “一节。

为了避免把时间浪费在开发人员身上，因为他们最终也帮不了你，你几乎总是想检查一下你所面临的问题是否也会在主线中出现–如果是的话，就把它作为主线中的 bug 直接报告给常规开发人员。在这种情况下，只要常规开发人员稍后将修复标记为反向移植，稳定版团队就根本不需要参与。

这个建议有一个例外：稳定版或长期系列中的回归。

直接向稳定版团队报告这些问题是可以的，因为运气好的话，他们已经知道了这个问题。但稳定版团队必须覆盖所有内核，所以他们往往不知道问题的存在，然后通常会要求您将问题一分为二。这时，你最好再检查一下主线中是否也出现了完全相同的回归。因为如果发生了，就应该让常规开发人员（稳定团队在 CC 中）参与进来，这样就能大大增加幸运和避免分段的机会，因为这些开发人员比稳定团队更了解自己的内核区域。这就是为什么你可能首先要检查主线，即使你处理的是稳定版或长期系列中的回归问题。

稳定团队在 Linux 内核开发过程中的固定方式导致了各种隐藏的、稍显不直观的方面。其中之一就是绝大多数发生在稳定内核和长期内核上的错误，最终都必须由主线的普通开发人员先行修复。这是因为这些内核中的许多 Bug 有两种类型：

  • 长期内核所基于的主线版本中已经存在的错误。
  • Bug 是由反向移植导致的，而反向移植会导致主线版本出现同样的回归。

在这两种情况下，让常规开发人员在主线版本中解决问题符合每个人的利益，因为他们最了解特定的代码；这还能确保修复程序的开发和测试安全地远离常规用户。

由于采用了这种策略，当您从长期版本（如 v5.10.y）升级到包含修复程序的后期主线版本（如 5.19）或由其衍生的稳定版本（v5.19.y）时，错误就不会再出现了。这种方法还允许协调反向移植，因为如果应用于 v5.10.y 长期系列的修复因某种原因没有应用到 5.15.y 等后期长期系列，就会出现类似的问题。

此外，这种工作流程还能在反向移植之前安全地评估修复及其先决条件，如果这样做风险太大，他们可能会放弃，除非是解决反向移植提交中的回归问题。在这种情况下，你必须更新到较晚的内核系列才能避免这种情况；内核开发人员承认这并不理想，但认为这是两个糟糕选择中较好的一个。

最终，只有两种 Bug 将主要由稳定版团队处理（如上所述，直接向他们报告也是可以的）：

  • 长期内核系列中从未在主线中出现过的回归，因为它们是由损坏或不完整的回传引起的。
  • 已在主线中修复的长期内核系列中的缺陷。

还有一些 bug 在主线中得到了解决，但却没有将修复程序回传，这可能是出于高风险的考虑，也可能是因为没有人想到这一点。在后一种情况下，如果有人找到了修复方法，稳定版团队可能会愿意提供帮助，而你可能是唯一一个有足够动力这样做的人。之后，必须有人检查补丁是否能在特定的长期系列上干净利落地应用，是否能解决问题，是否会产生任何回归；同样，这可能也是只有你才有足够动力去做的事情。请参阅 “开发人员有时希望得到你的帮助”、”开发人员有时依赖于你的帮助 “和 “Linux 内核范围内的开发人员都是志愿者，不欠你任何东西。”以了解为什么会这样。

开发人员经常需要您的帮助（参见下一点）。但即使开发人员不需要您的帮助，他们也会经常要求您提供有关错误的详细信息。请提供这些信息，否则开发人员可能不会有足够的动力来研究您的问题：

  • 他们可能会怀疑是配置或硬件问题导致了问题。
  • 他们可能会怀疑这是一个必须由其他人来处理的问题：问题出现的区域与问题产生的区域不同是很常见的，而负责前者的开发人员可能对后者一无所知。

有时，开发人员不仅希望得到您的帮助（见上一点），而且依赖您的帮助来解决问题。因为在很多情况下，他们无法在本地重现问题，因为大部分内核都是驱动程序。因此，许多问题只会在特定环境中出现，因此可能是您的特定平台、外设、发行版和配置组合所特有的问题。开发人员需要您提供调试和测试结果，否则他们可能无法理解和解决问题。

在错误修复过程中，开发人员可能会要求您测试建议的修复。在这种情况下，您的帮助符合每个人的利益，因为开发人员可能无法在实践中验证更改（参见 “开发人员有时需要您的帮助”）。同样经常发生的情况是，修复程序在开发人员的机器上运行良好，但在您的机器上却可能无法解决问题，或导致新的错误。

Linux 内核开发人员对错误的处理方式各不相同–甚至有些开发人员根本不会对某些方面存在缺陷的报告作出回应。您可以让您的报告看起来像开发人员认为值得花时间处理的东西，从而降低这种风险：

  • 避免本文所述的任何错误。最重要的是：使用全新的、虚无的、最好是自编译的内核进行报告。除了在稳定或长期内核中出现回归的情况外，几乎所有情况下都是主线版本：这时使用受影响系列的最新版本就足够了。
  • 创建一份易于他人掌握的报告，并提供调试和测试补丁的帮助。
  • 及时回复询问。

使用自编译内核进行报告和提供帮助是这里最重要的两点，因为开发人员通常会将此理解为：您愿意并且很可能也有能力帮助解决问题。这样他们就更有可能认真对待报告。

本文文字及图片出自 Why your Linux kernel bug report might be fruitless

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注