The extern flag currently is not included in type dump files
(genksyms --dump-types). Include that flag there for completeness.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Trying to compile the v850 port brings many compile errors, one of them exists
since at least kernel 2.6.19.
There also seems to be noone willing to bring this port back into a usable
state.
This patch therefore removes the v850 port.
If anyone ever decides to revive the v850 port the code will still be
available from older kernels, and it wouldn't be impossible for the port to
reenter the kernel if it would become actively maintained again.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The usage does not mention the "-a,--arch" or "-T,--dump-types" options, so
add them. The calls to getopt() seem to mention options that no longer exist
(some "k" and "p" thingy) but omits the "h" option which means using '-h'
actually triggers the error code path, so update those as well.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This adds support for the Analog Devices Blackfin processor architecture, and
currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561
(Dual Core) devices, with a variety of development platforms including those
avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP,
BF561-EZKIT), and Bluetechnix! Tinyboards.
The Blackfin architecture was jointly developed by Intel and Analog Devices
Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in
December of 2000. Since then ADI has put this core into its Blackfin
processor family of devices. The Blackfin core has the advantages of a clean,
orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC
(Multiply/Accumulate), state-of-the-art signal processing engine and
single-instruction, multiple-data (SIMD) multimedia capabilities into a single
instruction-set architecture.
The Blackfin architecture, including the instruction set, is described by the
ADSP-BF53x/BF56x Blackfin Processor Programming Reference
http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf
The Blackfin processor is already supported by major releases of gcc, and
there are binary and source rpms/tarballs for many architectures at:
http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete
documentation, including "getting started" guides available at:
http://docs.blackfin.uclinux.org/ which provides links to the sources and
patches you will need in order to set up a cross-compiling environment for
bfin-linux-uclibc
This patch, as well as the other patches (toolchain, distribution,
uClibc) are actively supported by Analog Devices Inc, at:
http://blackfin.uclinux.org/
We have tested this on LTP, and our test plan (including pass/fails) can
be found at:
http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel
[m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files]
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: Aubrey Li <aubrey.li@analog.com>
Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here is a patch that adds a new -T option to genksyms for generating dumps of
the type definition that makes up the symbol version hashes. This allows to
trace modversion changes back to what caused them. The dump format is the
name of the type defined, followed by its definition (which is almost C):
s#list_head struct list_head { s#list_head * next , * prev ; }
The s#, u#, e#, and t# prefixes stand for struct, union, enum, and typedef.
The exported symbols do not define types, and thus do not have an x# prefix:
nfs4_acl_get_whotype int nfs4_acl_get_whotype ( char * , t#u32 )
The symbol type defintion of a single file can be generated with:
make fs/jbd/journal.symtypes
If KBUILD_SYMTYPES is defined, all the *.symtypes of all object files that
export symbols are generated.
The single *.symtypes files can be combined into a single file after a kernel
build with a script like the following:
for f in $(find -name '*.symtypes' | sort); do
f=${f#./}
echo "/* ${f%.symtypes}.o */"
cat $f
echo
done \
| sed -e '\:UNKNOWN:d' \
-e 's:[,;] }:}:g' \
-e 's:\([[({]\) :\1:g' \
-e 's: \([])},;]\):\1:g' \
-e 's: $::' \
$f \
| awk '
/^.#/ { if (defined[$1] == $0) {
print $1
next
}
defined[$1] = $0
}
{ print }
'
When the kernel ABI changes, diffing individual *.symtype files, or the
combined files, against each other will show which symbol changes caused the
ABI changes. This can save a tremendous amount of time.
Dump the types that make up modversions
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
o remove all inlines
o declare everything static which is only used by genksyms.c
o delete unused functions
o delete unused variables
o delete unused stuff in genksyms.h
o properly ident genksyms.h
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
genksyms needs to know when a symbol must have a "_" prefex as is
true for a few architectures.
Pass $(ARCH) as commandline argument and hardcode what architectures that
needs this info.
Previous attemt to take it from elfconfig.h was br0ken since elfconfig.h
is a generated file.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The scripts/genksyms/genksyms.c uses hardcoded "__crc_" prefix for
crc symbols in kernel and modules. The prefix should be replaced by
"MODULE_SYMBOL_PREFIX##__crc_" otherwise there will be warnings when
MODULE_SYMBOL_PREFIX is not NULL.
I am sorry my last patch for this issue is actually wrong. I revert
it in this patch.
Signed-off-by: Luke Yang <luke.adi@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
