wiki.osdev.org 系列之（二）- How To Ask Questions

type

status

slug

summary

1 身份和用户帐户

花时间预先建立一个用户帐户，有一个可识别的用户名和头像。您的用户帐户为我们提供了一种私下联系您的方式，如果我们认为回复离题或太长，我们会通过电子邮件发送回复。独特的头像有助于一眼就认出你的帖子。能够避免试图根据问题描述和IP地址找出“aetroi”和“sdfoiu”是否是同一个人，从而导致一次又一次地问同样的问题的现象的出现。

注意: 注册OSDev.org论坛是强制性的。作为注册的一个好处，你也可以获得wiki的编辑权限。

2 标题

这有助于我们识别已知的主题。“内核问题”是个非常糟糕的标题。“IVT问题”是一个稍微好一点的主题。“鼠标移动时的中断处理程序三重错误”是一个很好的主题。由于论坛流量的不断增加，大多数论坛常客并不会阅读每个主题（同时也几乎不可能(尤其是在OS开发分论坛)）。一个好的标题能够准确吸引住真正了解这个主题的人的注意力。

3 语法

糟糕的语法、拼写和/或标点符号会让你的帖子更难理解。调试你的语言而不是调试你的问题，最终会让人们忽略你的帖子。远离 1337 和 SMS 快捷方式。基本上，使用正确的英语（无论是英国还是美国的拼写在很大程度上无关紧要）

顺便说一句，OSDev.org论坛目前没有任何非英语语言的子论坛。这是有意的。将论坛分割得越多，就意味着阅读和回答每个话题的人越少。Eric S. Raymond还指出，一般来说，编程(尤其是操作系统开发)是一个使用大量英语单词的主题，退一步来说，用英语交流会让交流更容易。

4 编程背景

OS开发不是一个学习如何用C、汇编或任何其他语言进行编程的合理场所，这一点在这个wiki和论坛规则中都有指出。这些警告是有原因的，并且提出一个向我们表明您没有阅读和理解这些规则或选择忽略它们的问题，在这里不太可能获得太多同情。

的确，操作系统开发论坛以对新手苛刻而闻名。这是有原因的: OS开发不是一个新手程序员可以合理接近的话题。许多人过早地进入这个领域——在他们有着必要的背景和经验来真正理解他们在做什么之前——并因缺乏准备而受到伤害。从而导致我们一次又一次地看到许多相同的错误和问题，如果发帖人阅读了这些警告并遵循了对应的建议，这些错误和问题是可以避免的。

这不是您可以通过简单的教程学习的领域，特别是如果您只是复制和粘贴教程代码并试图在不理解它的情况下使其工作。确实存在的这样的教程嘛——对于这个领域的大多数主题来说，没有，也不可能有——因为我们只是指导方针，而不是详细的食谱。从几个不同的现有源代码中剪切和粘贴代码，并期望它们神奇地组合在一起，这对于操作系统开发来说是不可行的。在你期望以有意义的方式进入这个领域之前，你需要学习很多东西，从而保证你彻底理解你在做什么。

5 研究

维基经常被扩展和修改。你的问题的答案很可能已经在里面了。尤其是你在开发周期的早期遇到的问题：诸如中断、设置 GCC 交叉编译器和打印到屏幕等，wiki 中已经为这些主题提供了大量的信息。

如果你正在使用一个更常见的教程/示例内核，你的问题可能已经在论坛中得到回答。使用论坛搜索功能，查找答案。

如果你的问题是“我在哪里可以找到X”，或者“有没有任何程序可以做Y”，搜索引擎几乎肯定会给你一个比我们这里更快，甚至可能更明智的答案。

一旦你找到了一个解决方案，坚持下去是很常见的——这里的许多人可以给你一两个选择，但可能会错过最适合你的那个。

通过询问诸如“如何从 FAT 磁盘读取数据？”、“如何加载程序？”或“是否有任何内存管理教程？”之类的一般性问题，你不太可能得到你想要的答案。问这样的问题表明你缺乏基本的编程技能；程序员应该能够自己解决问题，这清楚地表明他/她没有做研究。一个好的例子是把问题重新表述为“我正在尝试做x，我已经做了Y，但是我没有完全理解z。”

5.1 关于过时或不完整的维基文章

任何大型合作项目，如wiki，都不可避免地会有一些信息在没有被注意到的情况下过时，这是一个可悲的事实。同样不可避免的是，一些主题根本没有得到他们需要的关注。如果你注意到一些你认为发生了这种情况的事情，请尽量不要生气；相反，礼貌地把它放在留言板上，以便某人（可能是您自己）可以添加和/或更新它。

可能是直到现在才被发现，或者还没有主题专家解决这个问题；也有可能是有人为了做一个大的修改，把这个页面的副本挂到了自己的私人页面上，这还没有反映在官方页面上。甚至有可能是关于如何解决这个问题的争论，推迟了计划中的更新。相反，你可能在其他地方错过了一些东西(鉴于维基的规模和蔓延，这肯定会发生)，熟悉这个主题的论坛访客可以给你指出正确的方向。在这两种情况下，更好的办法是积极主动，而不是火上浇油。

6 细节

操作系统代码是高度相互依赖的。如果您只给我们提供三重故障的中断处理程序的源代码，我们将无法在您的 IVT 设置中找到实际导致错误的 bug。我们还需要知道您使用的是什么编译器/汇编器/链接器，哪个版本，以及您使用的是哪个命令行选项。

在OS项目列表中创建一个描述您的项目和环境的条目，并将该条目的链接添加到您的论坛签名中，这也将允许我们快速获得诸如“您使用什么编译器？”或者“你的开发环境是怎样的？”或者“你在用GRUB吗？Bochs？VMware？”等等。

与给的信息太少一样，信息给的太多也是有害的。很容易给人错误的印象(“我有一个问题，但懒得缩小范围。给我修好！”).

虽然您的项目结构对您来说可能是完全符合逻辑和直观的，但其他人可能仍然会感到困惑，没有人喜欢通过几十个源文件来找出发生了什么。

尝试找到足以重现问题的最小代码子集。(这也是一种很好的调试技术；在这个过程中，您可能会自己找到错误。)

与往常一样，任何操作系统项目的一个关键组件都应该是场外源代码控制存储库；除了代码保留和备份方面的优势外，它还允许响应者查看有问题的代码，而无需费力地阅读大量代码帖子，或者不得不一遍又一遍地要求发布代码。如果您有这样的存储库（并且应该），一定要包含一个链接，指向您遇到问题的代码部分的位置。这将允许论坛访问者看到最新版本的代码，并直接参考它。如前所述，您应该将代码帖子限制在您遇到问题的那部分代码上；如果证明问题出在其他地方，回购协议应该允许这一点随着时间的推移得到确定。

7 格式化

该论坛有一个 [code] ... [/code] 格式化命令，您可以使用它来突出显示您的代码片段并避免表情符号/字体化标签弄乱您的帖子。

把你的帖子分成几句话的段落。不要大喊大叫（例如用大写字母书写）或使用漂亮但无用的格式（例如发光的彩色字体、移动文本、表情符号等）。如果可能，请使用“预览”功能。

8 描述目标

当一个人在处理一个特定的问题 X 时，找到一个看起来很合适但您不知道如何正确实施或调试有问题的解决方案 Y 并不少见。这可能会导致您发布有关如何正确执行 Y 的问题。这很好，只是在不解释为什么要解决问题 Y 的上下文（问题 X）的情况下这样做可能会得到解决 Y 的答案，但不是以解决 X 的方式。实际上，可能是 Y 没有或根本无法解决 X，或者您不知道有一个明显更好的 X 的解决方案。在这种情况下，询问 Y 会让你走入死胡同。同时，它可能会让那些可以回答的人对你的目标感到困惑，导致他们根本不回答，即使他们实际上可能知道如何解决 X。

这种错误的解决方案被称为XY问题(或者更幽默地说，一个“瓶子或旧鞋”问题)，这是论坛上最令人沮丧的沟通问题之一。

为了避免这种情况，你应该仔细考虑在寻求帮助时，你是否已经对你试图完成的事情做了足够的解释。你不需要详细描述你的项目，但是简要描述一下近期目标(以及你过去使用过的任何解决方案)可以为回答者提供足够的背景知识来回答你的问题。

9 识别问题并向他人描述

在发帖之前，尽可能地隔离你的问题，并在帖子中提供尽可能多的信息。信息太少和太多都会增加回答问题的难度，但总的来说，太多总比太少好。

一般来说，在寻求编程帮助时，通常建议提供一个与实际代码库隔离的简短、自包含、正确（可编译）的示例。然而，在OS Dev中，这可能是不可能的，因为bug通常与整体环境密切相关，并且在任何情况下，为内核或驱动程序操作隔离代码都是不可能的。如果你能给出一个——即使它需要一些额外的脚手架——那么就这样做，因为它将把问题从无关的细节中分离出来，但是如果你不能，我们不会责备你(尽管如果你不愿意，我们可能会责备你，因为不尝试一下是不礼貌的)。

9.1 发布代码示例与链接到存储库

在解释问题时，您可能需要提供问题部分的代码示例，或指向代码存储库的链接，或者两者都提供。一般来说，在发布代码示例时，您希望给出足够的代码来说明问题，而不是更多。然而，很难判断到底有多少。此外，极长的代码样本往往很难在帖子中通读，所以如果你的代码片段中有超过(比如说)50行代码，最好链接到它。即使使用较小的片段，包括指向您的存储库的链接，我们也很感激，因为它可以让我们获得一些关于该问题的额外上下文。

请注意，仅发布代码或 repo 链接并告诉我们“这不起作用”是不够的。简单地给出一个大的代码示例或一个repo的链接，并期望我们回答你的问题，而不至少告诉我们你认为问题在代码库中的什么地方，这是非常不礼貌的。这样做而不解释故障模式(即，发生了什么或没有发生什么)更是如此。有人会认为这不需要说，但显然它需要。

遵循上面的指导方针会大大提高你得到快速而有用的回复的机会。(这让帮助你变得更有趣，所以那些知道诀窍的人会留下来，明天仍然可以帮助你。)