+ 第十九章:内联汇编
+
+在特定架构的代码中,你也许需要内联汇编来使用 CPU 接口和平台相关功能。在需要
+这么做时,不要犹豫。然而,当 C 可以完成工作时,不要无端地使用内联汇编。如果
+可能,你可以并且应该用 C 和硬件交互。
+
+考虑去写通用一点的内联汇编作为简明的辅助函数,而不是重复写下它们的细节。记住
+内联汇编可以使用 C 参数。
+
+大而特殊的汇编函数应该放在 .S 文件中,对应 C 的原型定义在 C 头文件中。汇编
+函数的 C 原型应该使用 “asmlinkage”。
+
+你可能需要将你的汇编语句标记为 volatile,来阻止 GCC 在没发现任何副作用后就
+移除了它。你不必总是这样做,虽然,这样可以限制不必要的优化。
+
+在写一个包含多条指令的单个内联汇编语句时,把每条指令用引号字符串分离,并写在
+单独一行,在每个字符串结尾,除了 \n\t 结尾之外,在汇编输出中适当地缩进下
+一条指令:
+
+ asm ("magic %reg1, #42\n\t"
+ "more_magic %reg2, %reg3"
+ : /* outputs */ : /* inputs */ : /* clobbers */);
+
+
+ 第二十章:条件编译
+
+只要可能,就不要在 .c 文件里面使用预处理条件;这样做让代码更难阅读并且逻辑难以
+跟踪。替代方案是,在头文件定义函数在这些 .c 文件中使用这类的条件表达式,提供空
+操作的桩版本(译注:桩程序,是指用来替换一部分功能的程序段)在 #else 情况下,
+再从 .c 文件中无条件地调用这些函数。编译器会避免生成任何桩调用的代码,产生一致
+的结果,但逻辑将更加清晰。
+
+宁可编译整个函数,而不是部分函数或部分表达式。而不是在一个表达式添加 ifdef,
+解析部分或全部表达式到一个单独的辅助函数,并应用条件到该函数内。
+
+如果你有一个在特定配置中可能是未使用的函数或变量,编译器将警告它定义了但未使用,
+标记这个定义为 __maybe_unused 而不是将它包含在一个预处理条件中。(然而,如果
+一个函数或变量总是未使用的,就直接删除它。)
+
+在代码中,可能的情况下,使用 IS_ENABLED 宏来转化某个 Kconfig 标记为 C 的布尔
+表达式,并在正常的 C 条件中使用它:
+
+ if (IS_ENABLED(CONFIG_SOMETHING)) {
+ ...
+ }
+
+编译器会无条件地做常数合并,就像使用 #ifdef 那样,包含或排除代码块,所以这不会
+带来任何运行时开销。然而,这种方法依旧允许 C 编译器查看块内的代码,并检查它的正确
+性(语法,类型,符号引用,等等)。因此,如果条件不满足,代码块内的引用符号将不存在,
+你必须继续使用 #ifdef。
+
+在任何有意义的 #if 或 #ifdef 块的末尾(超过几行),在 #endif 同一行的后面写下
+注释,指出该条件表达式被使用。例如:
+
+ #ifdef CONFIG_SOMETHING
+ ...
+ #endif /* CONFIG_SOMETHING */
+