今天发现THIS_MODULE 宏不存在，原来是在linux/modules.h 中，先在被搬到了新增的export.h 里了。该头文件这样说道：
4 * Export symbols from the kernel to modules. Forked from module.h
5 * to reduce the amount of pointless cruft we feed to gcc when only
6 * exporting a simple symbol or two.
8 * If you feel the need to add #include <linux/foo.h> to this file
9 * then you are doing something wrong and should go away silently.
12 /* Some toolchains use a `_' prefix for all user symbols. */
导出内核符号到内核模块。减少因仅仅导出一两个内核符号而包含整个module.h ，减少gcc的编译负担 ，所以就从module.h分离出来了export.h。如果你想往export.h里面塞入一些东西，那么你应该是想错了，不要去动他。
introduce export.h; reduce module.h usage
||Paul Gortmaker <email@example.com>
||[RFC/PULL 00/11] introduce export.h; reduce module.h usage
||Thu, 28 Jul 2011 01:16:07 -0400
||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
I don't think there really is any rocket science or contentious stuff here.
It is a sensible cleanup that adds organization and speeds up compiles.
The RFC I'm hoping for is more about how/when we want to get this in tree.
The module.h header file contains a path to nearly every other
header, and it itself is implicitly used everywhere. Such that if you
touch module.h and rebuild, it takes the same time as a completely clean
build. We are feeding massive amounts of needless stuff to cpp on every
kernel build. The "implicitly everywhere" problem is caused by common
header files (device.h, sock.h, etc) directly including module.h.
This also comes in two parts. We can drastically reduce the
users of module.h by introducing an export.h -- so that every file
who isn't a module, but needs EXPORT_SYMBOL/THIS_MODULE, can instead
just use this lightweight header which in turn doesn't include any
others. The "implicitly everywhere" can be solved by removing
module.h from all possible <linux/somefile.h> and replacing it with
a simple reference for "struct module".
Solving the implicitly everywhere problem reveals lots of files who
were unknowingly capitalizing on having module.h present for its
contents, and contents of the files it in turn included.
Shown here in this RFC are the just the include/* patches which form
these two solutions. What is *not* shown is the boring 150 or so
patches, all of the one-line variety, which deal with the fact that
people were implicitly taking advantage of module.h (and all its children
includes). These all fall into one of these five mundane categories.
1) adding module.h to files that were modular but were simply not
including module.h because of its implicit presence everywhere.
2) adding export.h to non-modular files that were not including module.h
but were trying to use EXPORT_SYMBOL/THIS_MODULE macros.
3) replacing module.h with export.h in non-modular files that are only
trying to use EXPORT_SYMBOL/THIS_MODULE macros.
4) adding in various other headers, like <linux/stat.h> that were simply
implicitly present via happenstance of the module.h's sub-includes.
5) deleting the <linux/module.h> from files who were including it but
not doing anything at all related to modules.
Note that #3 and #5 don't show up as warnings/errors, I had to actively
hunt out those optimizations manually. In total, all the one line
"fallout" changes add to this cleanup to give it this footprint:
1148 files changed, 1263 insertions(+), 428 deletions(-)
[If I knew it was going to be that involved, I'd probably would have
never undertaken to start this in the 1st place...]
I've kept these changes all grouped into arch and subsystem categories
in case people want to see this go in chunks via maintainer trees (as it
is much easier to combine things than try to "un-combine" things.)
For all 160 commits, the branch "module.h-split", available here:
has the complete content. I've put the header changes after all the
patches from the top 5 categories, so that people bisecting non related
issues at a later date don't get hit with a commit zone with build failures.
The original idea for this cleanup came from Ingo, and in that same
thread, I'd posted preliminary data on my work-in-progress. Also in the
thread, Ingo had some positive feedback (many thanks!) and benchmark
numbers, indicating that we really probably want to to go with this.
Since that discussion, I've spawned out to cover allyesconfig builds in
powerpc, sparc, arm, mips, x86, x86-64 in order to hunt down and squash
build failures caused by people assuming module.h content is present.
I am sure that some of the less common arch (DEC Alpha, etc.) may still
have some of these assumptions lingering in their arch specific drivers,
but I don't see fixing these outliers as they arise as an issue.
Anyway, unless there is considerable objection to what is here, I'd like
to have Linus simply pull this directly. That is what Ingo recommended,
and also my personal preference. But I'm OK with feeding it in chunkwise
via individual maintainer trees if people want that instead.