Linux 内核模块编译和 KBUILD_NOPEDANTIC
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/11077957/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Kernel module compilation and KBUILD_NOPEDANTIC
提问by dimba
I've noticed that recent kernels (starting from 2.16.24?) don't like if CFLAGSis changed in external module Kbuild file. If CFLAGSis changed you'll be issued the following error by Linux kernel Kbuild system:
我注意到最近的内核（从 2.16.24 开始？）不喜欢 ifCFLAGS在外部模块 Kbuild 文件中更改。如果CFLAGS更改，Linux 内核 Kbuild 系统会发出以下错误：
scripts/Makefile.build:46: *** CFLAGS was changed in "/some/path". Fix it to use EXTRA_CFLAGS. Stop.
From here:
从这里：
External modules have in a few cases modifed gcc option by modifying CFLAGS. This has never been documented and was a bad practice.
在少数情况下，外部模块通过修改 CFLAGS 修改了 gcc 选项。这从未被记录在案，而且是一种不好的做法。
Additional emailfrom LKML.
email来自 LKML 的补充。
Why is it bad idea? What is rational?
为什么这是个坏主意？什么是理性？
回答by ugoren
Linux makefiles build CFLAGSin a way which is appropriate for the kernel.
Overriding CFLAGSmean you add some flags and may remove some flags. Some of the removed flags may be important for correct compilation.
Linux 生成文件CFLAGS以适合内核的方式构建。
覆盖CFLAGS意味着您添加一些标志并可能删除一些标志。一些已删除的标志对于正确编译可能很重要。
回答by Reinier Torenbeek
First of all, it might be worth mentioning that EXTRA_CFLAGShas been deprecated a while ago and is replaced by ccflags-y. You can read about the intention of ccflags-yin Documentation/kbuild/makefiles.txt, section 3.7.
首先，值得一提的EXTRA_CFLAGS是，不久前已被弃用并由ccflags-y. 你可以阅读有关的意向ccflags-y中Documentation/kbuild/makefiles.txt，第3.7节。
Basically, this variable allows you to append settings to the set of C compilation flags, within the scope of the file where it is assigned only. You are not supposed to change the global flags, because that mighthave a global impact beyond your own makefile, which is considered bad practice. The check that you mention verifies that indeed, the global flags did not get changed by included makefiles.
基本上，此变量允许您将设置附加到 C 编译标志集，仅在分配它的文件范围内。您不应该更改全局标志，因为这可能会产生超出您自己的 makefile 的全局影响，这被认为是不好的做法。您提到的检查确实验证了全局标志没有被包含的 makefile 更改。
It is interesting to check out how ccflags-y, formerly known as EXTRA_CFLAGS, ends up being used in the build process. Tracing some relevant points (but not all, because that is left as an exercise to the reader ;-) ) shows the following:
看看ccflags-y，以前称为EXTRA_CFLAGS，最终如何在构建过程中使用是很有趣的。追踪一些相关点（但不是全部，因为这留给读者作为练习;-)）显示以下内容：
EXTRA_CFLAGScan still be used, according to scripts/Makefile.lib
EXTRA_CFLAGS仍然可以使用，根据 scripts/Makefile.lib
1 # Backward compatibility
2 asflags-y += $(EXTRA_AFLAGS)
3 ccflags-y += $(EXTRA_CFLAGS)
The same file shows how ccflags-yends up in the C compilation flags (and also shows you that you have another variable at your disposal, called CFLAGS_<filename>.o):
同一个文件显示ccflags-y了 C 编译标志中的最终结果（并且还显示了您可以使用另一个变量，称为CFLAGS_<filename>.o）：
104 orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \
105 $(ccflags-y) $(CFLAGS_$(basetarget).o)
106 _c_flags = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags))
...
133 __c_flags = $(_c_flags)
...
147 c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
148 $(__c_flags) $(modkern_cflags) \
149 -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags)
Then in scripts/Makefile.build, the compilation rule is defined:
然后在 中scripts/Makefile.build，定义编译规则：
234 cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
Note that these are all recursively expanded variables, using =and not :=, which means that your own value of ccflags-ygets inserted into the C flags when you define it in your own makefile.
请注意，这些都是递归扩展的变量， using=和 not :=，这意味着ccflags-y当您在自己的 makefile 中定义它时，您自己的值会被插入到 C 标志中。
Finally about KBUILD_NOPEDANTIC, which you mention in the title but not in the actual question. This test for changed value of CFLAGScan be disabled by giving KBUILD_NOPEDANTICany value -- see scripts/Makefile.build
最后 about KBUILD_NOPEDANTIC，你在标题中提到但在实际问题中没有提到。CFLAGS可以通过提供KBUILD_NOPEDANTIC任何值来禁用此更改值的测试- 请参阅scripts/Makefile.build
47 ifeq ($(KBUILD_NOPEDANTIC),)
48 ifneq ("$(save-cflags)","$(CFLAGS)")
49 $(error CFLAGS was changed in "$(kbuild-file)". Fix it to use ccflags-y)
50 endif
51 endif
The files referenced in this answer were all retrieved today.
这个答案中引用的文件都是今天检索到的。
Now... not being an expert in this area and looking further into the makefiles after writing this whole story down, there is a thing that I do not understand either. It seems to me that CFLAGSis not used in the build system (not implicitly, nor explicitly), but KBUILD_CFLAGSis. So I wonder whether this check for changes in CFLAGSshould actually be a check for changes in KBUILD_CFLAGSinstead.
现在……我不是这方面的专家，而是在写下整个故事后进一步研究 makefile，还有一件事我也不明白。在我看来，CFLAGS它没有在构建系统中使用（不是隐式，也不是显式），而是KBUILD_CFLAGS。所以我想知道这种对 变化的检查是否CFLAGS实际上应该是对变化的检查KBUILD_CFLAGS。
