| Age | Commit message (Collapse) | Author |
|---|
|
From: Al Viro <viro@ZenIV.linux.org.uk>
Instead of playing all of these hand-coded assembler aliasing games,
just translate symbol names in the name space ".sym" to "_Sym" at
module load time.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
GLIBC 2.3.4 and later changed the STT_REGISTER macro to
STT_SPARC_REGISTER, so we need to cope with that somehow.
Original patch from fabbione, reposted by Ben Collins.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The kbuild utilities are compiled with absolute patch names, so paths
starting with $RPM_BUILD_ROOT would end up in the binaries. To avoid
this, remove all references to __FILE__ (directly and indirectly via
assert()).
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
A coworker of mine give them a look-over and spotted a few
places where I missed changing some casts.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
The following set of patches is based loosely on the patches that
Jean-Christophe Dubois came up with for 2.6.7. Where as the original
patches added a number of casts to unsigned char, I went the route of
making the chars be explicitly signed. I honestly don't know which
route is better to go down. Doing this is the bulk of the patch. Out
of the rest of the odds 'n ends is that on Solaris, Elf32_Word is a
ulong, which means all of the printf's are unhappy (uint format, ulong
arg) for most of the typedefs.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Weak symbol may be unavailable in kernel, but if it is available, its
signature should be same as was at the build time. If we do not attach
signatures to weak symbols, kernel is tainted when such module is loaded.
vmmon: no version for "sys_ioctl" found: kernel tainted.
I also believe that it is safer to add & check signatures here - module
wants either sys_ioctl with right signature, or no sys_ioctl at all, not
sys_ioctl with different signature (which signals that there is some
misbuild occuring).
Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (forwarded)
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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>
|
|
This patch removes the default stubs for init_module and cleanup_module,
and checks for NULL instead. It changes modpost to only create references
to those functions if they actually exist.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.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>
|
