| Age | Commit message (Collapse) | Author |
|---|
|
Separate the module source and header checksum into a separate modinfo
field srcversion.
With CONFIG_MODULE_SRCVERSION_ALL=y, put srcversion into every module, not
just those with MODULE_VERSION("something").
Patch by Rusty Russell, trivial merging and testing by Matt Domsch
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
When building allmodconfig the following error were seen:
scripts/Makefile.modpost:86: target `fs/nls/nls_koi8-ru.ko' given more than once in the same rule.
This happened for all modules with 'ko' inside their name.
This bug were introduced when head ... were replaced by grep.
Signed off by: Sam Ravnborg <sam@ravnborg.org>
|
|
Additional Makefile fixes for Solaris 2.8
On Solaris, 'head' doesn't take a -q argument. But we can use 'grep -h'
instead, so do that in Makefile.mod{inst,post}. The built-in test to
/bin/sh doesn't like 'if ! cmd' syntax, so when determining if we need
to do modversion stuff, invert the if/else cases. The built-in test
also doesn't understand -ef, so invoke a real version of test which does.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
From: Pavel Roskin <proski@gnu.org>
The recent fixes for the external module build have fixed the major
breakage, but they left one annoyance unfixed. If CONFIG_MODVERSIONS is
disabled, a warning is printed for every exported symbol that is has no
CRC. For instance, I see this when compiling the standalone Orinoco
driver on Linux 2.6.6-rc3:
*** Warning: "__orinoco_down" [/usr/local/src/orinoco/spectrum_cs.ko] has
no CRC!
*** Warning: "hermes_struct_init" [/usr/local/src/orinoco/spectrum_cs.ko]
has no CRC!
*** Warning: "free_orinocodev" [/usr/local/src/orinoco/spectrum_cs.ko] has
no CRC!
[further warnings skipped]
I have found that the "-i" option for modpost is used for external builds,
whereas the internal modules use "-o". The "-i" option causes read_dump()
in modpost.c to be called. This function sets "modversions" variable
under some conditions that I don't understand. The comment before the
modversions declarations says: "Are we using CONFIG_MODVERSIONS?"
Apparently modpost fails to answer this question. I think it's better to
use an explicit option rather than a kludge.
The attached patch adds a new option "-m" that is specified if and only if
CONFIG_MODVERSIONS is enabled. The patch has been successfully tested
both with and without CONFIG_MODVERSIONS.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Move modpost and support files to scripts/mod.
Directory named mod by Sam.
From: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Process modules in sorted order during modpost and modules install.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Sam Ravnborg <sam@ravnborg.org>
The external module support recently introduced caused a number of problems:
- To build an external module the Module.symvers file was needed
- To create the Module.symvers file a module was required
- If Module.symvers was missing kbuild boiled out with an error
- If vmlinux was missing also the stage 2 of module build failed (make -k)
- It was not documented what was needed to actually bauild a module
The following patch addresses this by adding the following functionality:
- Always generate the Module.symvers file
- Ignore a missing Module.symvers file
- Add a new target modules_prepare, it prepares the kernel for building
external modules, and is also usefull with O=
- And it adds some more comments to Makefile.modpost, so others may follow
it with some luck
- .modpost.cmd is no longer generated
This should close all reports on issues with respect to building external
modules with current kernel - which has been identified as kernel problems.
|
|
From: Sam Ravnborg <sam@ravnborg.org>
Based on initial patch from Andreas Gruenbacher there is now better support
for building external modules with kbuild.
The preferred syntax is now:
make -C $KERNELSRC M=$PWD
but the old syntax:
make -C $KERNELSRC SUBDIRS=$PWD modules
will remain supported.
The major differences compared to before are that:
1) No attempt is made to neither check nor update any files in $KERNELSRC
2) Module versions are now supported
During stage 2 of kernel compilation where the modules are built, a new file
Module.symvers is created. This file contains the version for all symbols
exported by the kernel and any module compiled within the kernel tree.
When the external module is build the Module.symvers file is being read and
symbol versions are used from that file.
The purpose of avoiding any updates in the kernel src is that usually in a
distribution the kernel src will be read-only, and there is no need to try to
update it. And when building an external module the focus is on the module,
not the kernel.
I expect the distributions will start using something like this:
kernel src - with no generated files. Not even .config:
/usr/src/linux-<version>
Output from build:
/lib/modules/linux-<version>/build
where build is a real directory with relevant output files and the
appropriate .config.
I have some Documentation in the pipe-line, but wants to see how this
approach is received before completing it.
This patch is made on top of the previously posted patch to divide
make clean in three steps.
And you may need to edit the following line in the patch to make it apply:
%docs: scripts_basic FORCE
to
%docs: scripts FORCE
|
|
From: Brian Gerst <bgerst@didntduck.org>
Move the __this_module structure to the modpost code where it really
belongs.
|
|
From: Rusty Russell <rusty@rustcorp.com.au>
Now kbuild prints out a line telling only what modules there are added,
not all modules.
|
|
From: Rusty Russell <rusty@au1.ibm.com>
The way it works is that the .mod file contains the name of the module (as
before), but succeeding lines are the constituent parts (assumed to be .c
files, which usually works: if they use MODULE_VERSION in a file for which
this isn't true we'll get a warning).
As we postprocess modules, we look in the .modinfo section for a
"version=", which is placed by the MODULE_VERSION() macro. This will be of
form "version=<macroarg>" "\0" [24 chars] "\0". The 24 chars are replaced
by the md4 sum of the .c files and any files they #include using '#include
"file"' which are found in the current directory. Whitespace is collapsed
outside strings, and comments are ignored for purposes of the sum.
The result is a .modinfo entry such as
version=1.16ac-rustytest B13E9451C4CA3B89577DEFF
At the kernel summit, various people asked for a MODULE_VERSION macro to
store module strings (for later access through sysfs). A simple md4 is
needed to identify changes in modules which, inevitably, do not update the
version. It skips whitespace and comments, and includes #includes which
are in the same dir.
The module versions should be set according to this definition, based on
the RPM one, or CVS Revision tags. Violators will be shot.
[<epoch>`:']<version>[`-'<extraversion>]
<epoch>: A (small) unsigned integer which allows you to start versions
anew. If not mentioned, it's zero. eg. "2:1.0" is after
"1:2.0".
<version>: The <version> may contain only alphanumerics.
<extraversion>: Like <version>, but inserted for local
customizations, eg "rh3" or "rusty1".
Comparison of two versions (assuming same epoch):
Split each into all-digit and all-alphabetical parts. Compare each one one
at a time: digit parts numerically, alphabetical in ASCII order. So 0.10
comes after 0.9.
|
|
Separate output directory support enables the following (at least):
o Building several configurations from the same SRC base, and in parrallel
o Building from a RO media
o More efficient build if files are retreived via NFS (files stored locally)
Usage is simple:
cd /path/to/kernel/src
mkdir ~/build/kernel
make O=~/build/kernel [Make options]
Please note: The O= syntax must be used for ALL invocations of make.
As an alternative you may set KBUILD_OUTPUT to the directory where
to put the output files.
The patch works for me, and I have tried with various configurations,
including allnoconfig and defconfig.
How it works:
If the O= option is used, or KBUILD_OUTPUT is set then a second invocation
of make happens in the output directory.
The second invocation of make uses VPATH to tell make where to locate
the files. Furthermore include options for gcc is modifyied to point
both in the directory where the kernel src is located, and in the
directory where the output files are located. The latter is used for
generated .h files.
When building the kernel the asm symlink is created. To support this
a new 'include2' directory is created. Within include2/ asm is a symlink to
the asm-$(ARCH) directory in the kernel src.
Also when building the kernel the asm-offset.h file is created, and
located in the include/asm-$(ARCH) directory, but included via
<asm/asm-offset.h>.
Therefore within include/ another asm symlink is created pointing to
the asm-$(ARCH) directory located in the output directory.
In Makefile.build the output directory is created if not already present.
This was needed to support xfs, and oprofile.
The patch is loosly based on ideas from Kai G. Roman Zippel
introduced support for this in kconfig long time ago
|
|
For some reason which I cannot remember, we didn't use the automatic
dependency generation for the generated .mod.[co] files. However, we do
of course need dependency information for those, too, they need to be updated
when e.g. the kernel version number changes.
|
|
Those were missing, not particularly harmful, but still needed for
correctness.
|
|
We had a dummy dependency on include/linux/compile.h, but it really caused
more trouble than benefits. It's not actually needed for the module
postprocessing, it was only put there to make sure we recognize when
gcc changed under us. However, we really can only do so much, and
the rest of kbuild won't notice a changed gcc either, so if the user replaces
gcc during a build, he just can't rely on the build doing the right thing.
The common cases are still covered, anyway. When the command to invoke
gcc changes ("CC=gcc32") we notice, and when the path to
/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h
changes (which luckily contains the "2.96", we'll notice and handle that,
too.
|
|
Since it's now not only used for modversioning but generally, rename
the Makefile .modver -> .modpost and the generated files to
<module>.ver.[co].
Also, when there's now vmlinux during module postprocessing, don't print
warnings on unresolved symbols (there's just too many, then).
|
