Documentation/translations/zh_CN/process/3.Early-stage.rst

   1 .. include:: ../disclaimer-zh_CN.rst
   2
   3 :Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
   4
   5 :Translator:
   6
   7  时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
   8
   9 :校译:
  10
  11  吴想成 Wu XiangCheng <bobwxc@email.cn>
  12
  13 .. _cn_development_early_stage:
  14
  15 早期规划
  16 ========
  17
  18 当考虑一个Linux内核开发项目时，很可能会直接跳进去开始编码。然而，与任何重要
  19 的项目一样，许多成功的基础最好是在第一行代码编写之前就打下。在早期计划和
  20 沟通中花费一些时间可以在之后节省更多的时间。
  21
  22 搞清问题
  23 --------
  24
  25 与任何工程项目一样，成功的内核改善从清晰描述要解决的问题开始。在某些情况
  26 下，这个步骤很容易：例如当某个特定硬件需要驱动程序时。不过，在其他情况下，
  27 很容易将实际问题与建议的解决方案混在一起，这可能会导致麻烦。
  28
  29 举个例子：几年前，Linux音频的开发人员寻求一种方法来运行应用程序，而不会因
  30 系统延迟过大而导致退出或其他问题。他们得到的解决方案是一个连接到Linux安全
  31 模块（LSM）框架中的内核模块；这个模块可以配置为允许特定的应用程序访问实时
  32 调度程序。这个模块被实现并发到linux-kernel邮件列表，在那里它立即遇到了麻烦。
  33
  34 对于音频开发人员来说，这个安全模块足以解决他们当前的问题。但是，对于更广泛的
  35 内核社区来说，这被视为对LSM框架的滥用（LSM框架并不打算授予他们原本不具备的
  36 进程特权），并对系统稳定性造成风险。他们首选的解决方案包括短期的通过rlimit
  37 机制进行实时调度访问，以及长期的减少延迟的工作。
  38
  39 然而，音频社区无法超越他们实施的特定解决方案来看问题；他们不愿意接受替代方案。
  40 由此产生的分歧使这些开发人员对整个内核开发过程感到失望；其中一个开发人员返回
  41 到audio列表并发布了以下内容：
  42
  43         有很多非常好的Linux内核开发人员，但他们往往会被一群傲慢的傻瓜所压倒。
  44         试图向这些人传达用户需求是浪费时间。他们太“聪明”了，根本听不到少数
  45         人的话。
  46
  47 （http://lwn.net/articles/131776/）
  48
  49 实际情况却是不同的；与特定模块相比，内核开发人员更关心系统稳定性、长期维护
  50 以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上——而不是具体的
  51 解决方案上——并在开始编写代码之前与开发社区讨论这个问题。
  52
  53 因此，在考虑一个内核开发项目时，我们应该得到一组简短问题的答案：
  54
  55  - 需要解决的问题究竟是什么？
  56
  57  - 受此问题影响的用户有哪些？解决方案应该解决哪些使用案例？
  58
  59  - 内核现在为何没能解决这个问题？
  60
  61 只有这样，才能开始考虑可能的解决方案。
  62
  63
  64 早期讨论
  65 --------
  66
  67 在计划内核开发项目时，在开始实施之前与社区进行讨论是很有意义的。早期沟通可以
  68 通过多种方式节省时间和麻烦：
  69
  70  - 很可能问题是由内核以您不理解的方式解决的。Linux内核很大，具有许多不明显
  71    的特性和功能。并不是所有的内核功能都像人们所希望的那样有文档记录，而且很
  72    容易遗漏一些东西。某作者发布了一个完整的驱动程序，重复了一个其不
  73    知道的现有驱动程序。重新发明现有轮子的代码不仅浪费，而且不会被接受到主线
  74    内核中。
  75
  76  - 建议的解决方案中可能有一些要素不适合并入主线。在编写代码之前，最好先了解
  77    这样的问题。
  78
  79  - 其他开发人员完全有可能考虑过这个问题；他们可能有更好的解决方案的想法，并且
  80    可能愿意帮助创建这个解决方案。
  81
  82 在内核开发社区的多年经验给了我们一个明确的教训：闭门设计和开发的内核代码总是
  83 有一些问题，这些问题只有在代码发布到社区中时才会被发现。有时这些问题很严重，
  84 需要数月或数年的努力才能使代码达到内核社区的标准。例如：
  85
  86  - 设计并实现了单处理器系统的DeviceScape网络栈。只有使其适合于多处理器系统，
  87    才能将其合并到主线中。在代码中修改锁等等是一项困难的任务；因此，这段代码
  88    （现在称为mac80211）的合并被推迟了一年多。
  89
  90  - Reiser4文件系统包含许多功能，核心内核开发人员认为这些功能应该在虚拟文件
  91    系统层中实现。它还包括一些特性，这些特性在不将系统暴露于用户引起的死锁的
  92    情况下是不容易实现的。这些问题过迟发现——以及拒绝处理其中一些问题——已经
  93    导致Reiser4置身主线内核之外。
  94
  95  - Apparmor安全模块以被认为不安全和不可靠的方式使用内部虚拟文件系统数据结构。
  96    这种担心（包括其他）使Apparmor多年来无法进入主线。
  97
  98 在这些情况下，与内核开发人员的早期讨论，可以避免大量的痛苦和额外的工作。
  99
 100 找谁交流？
 101 ----------
 102
 103 当开发人员决定公开他们的计划时，下一个问题是：我们从哪里开始？答案是找到正确
 104 的邮件列表和正确的维护者。对于邮件列表，最好的方法是在维护者(MAINTAINERS)文件
 105 中查找要发布的相关位置。如果有一个合适的子系统列表，那么其上发布通常比在
 106 linux-kernel上发布更可取；您更有可能接触到在相关子系统中具有专业知识的开发
 107 人员，并且环境可能具支持性。
 108
 109 找到维护人员可能会有点困难。同样，维护者文件是开始的地方。但是，该文件往往不
 110 是最新的，并且并非所有子系统都在那里显示。实际上，维护者文件中列出的人员可能
 111 不是当前实际担任该角色的人员。因此，当对联系谁有疑问时，一个有用的技巧是使用
 112 git（尤其是“git-log”）查看感兴趣的子系统中当前活动的用户。看看谁在写补丁、
 113 谁会在这些补丁上加上Signed-off-by行签名（如有）。这些人将是帮助新开发项目的
 114 最佳人选。
 115
 116 找到合适的维护者有时是非常具有挑战性的，以至于内核开发人员添加了一个脚本来
 117 简化这个过程：
 118
 119 ::
 120
 121         .../scripts/get_maintainer.pl
 122
 123 当给定“-f”选项时，此脚本将返回指定文件或目录的当前维护者。如果在命令行上
 124 给出了一个补丁，它将列出可能接收补丁副本的维护人员。有许多选项可以调节
 125 get_maintainer.pl搜索维护者的严格程度；请小心使用更激进的选项，因为最终结果
 126 可能会包括对您正在修改的代码没有真正兴趣的开发人员。
 127
 128 如果所有其他方法都失败了，那么与Andrew Morton交流是跟踪特定代码段维护人员
 129 的一种有效方法。
 130
 131 何时邮寄？
 132 ----------
 133
 134 如果可能的话，在早期阶段发布你的计划只会更有帮助。描述正在解决的问题以及已经
 135 制定的关于如何实施的任何计划。您可以提供的任何信息都可以帮助开发社区为项目
 136 提供有用的输入。
 137
 138 在这个阶段可能发生的一件令人沮丧的事情不是得到反对意见，而是很少或根本没有
 139 反馈。令人伤心的事实是：（1）内核开发人员往往很忙；（2）不缺少有宏伟计划但
 140 代码（甚至代码设想）很少的人去支持他们；（3）没有人有义务审查或评论别人发表
 141 的想法。除此之外，高层级的设计常常隐藏着一些问题，这些问题只有在有人真正尝试
 142 实现这些设计时才会被发现；因此，内核开发人员宁愿看到代码。
 143
 144 如果发布请求评论（RFC）并没得到什么有用的评论，不要以为这意味着无人对此项目
 145 有兴趣，同时你也不能假设你的想法没有问题。在这种情况下，最好的做法是继续进
 146 行，把你的进展随时通知社区。
 147
 148 获得官方认可
 149 -----------------------
 150
 151 如果您的工作是在公司环境中完成的，就像大多数Linux内核工作一样；显然，在您将
 152 公司的计划或代码发布到公共邮件列表之前，必须获得有适当权利经理的许可。发布
 153 不确定是否兼容GPL的代码尤其会带来问题；公司的管理层和法律人员越早能够就发布
 154 内核开发项目达成一致，对参与的每个人都越好。
 155
 156 一些读者可能会认为他们的核心工作是为了支持还没有正式承认存在的产品。将雇主
 157 的计划公布在公共邮件列表上可能不是一个可行的选择。在这种情况下，有必要考虑
 158 保密是否真的是必要的；通常不需要把开发计划关在门内。
 159
 160 的确，有些情况下一家公司在开发过程的早期无法合法地披露其计划。拥有经验丰富
 161 的内核开发人员的公司可能选择以开环的方式进行开发，前提是他们以后能够避免
 162 严重的集成问题。对于没有这种内部专业知识的公司，最好的选择往往是聘请外部
 163 开发者根据保密协议审查计划。Linux基金会运行了一个NDA程序，旨在帮助解决这种
 164 情况；更多信息参见：
 165
 166     http://www.linuxfoundation.org/nda/
 167
 168 这种审查通常足以避免以后出现严重问题，而无需公开披露项目。