Core ftrace support for the ARM architecture, which includes support
for dynamic function tracing.
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Martin Michlmayr reported that fuse complains:
ERROR: "copy_page" [fs/fuse/fuse.ko] undefined!
so export the needed function.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use the newly introduced __used attribute in place of the deprecated
__attribute_used__. Functionally the same.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
I've got the following linking error when building 2.6.21-mm2 on ARM:
ERROR: "csum_partial_copy_from_user" [net/rxrpc/af-rxrpc.ko] undefined!
Linking fails because "csum_partial_copy_from_user" is not exported to
modules. This patch adds it to the list of exported symbols.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
MMUless systems have only one address space for all threads, so
both the usual access_ok() checks, and the exception handling do
not make much sense.
Hence, discard the fixup and exception tables at link time, use
memcpy/memset for the user copy/clearing functions, and define
the permission check macros to be constants.
Some of this patch was derived from the equivalent patch by
Hyok S. Choi.
Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Back in the days when we had armo (26-bit) and armv (32-bit) combined,
we had an additional layer to the uaccess macros to ensure correct
typing. Since we no longer have 26-bit in this tree, we no longer
need this layer, so eliminate it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't
being exported from lib/string.c. Investigating further, I noticed a
changeset that removed its export and added it to _ksyms.c on a few more
architectures. The justification was that "other arches do it."
I think this is wrong, since no architecture currently defines
__HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it
themselves. Therefore, consolidate the export to lib/string.c.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Patch from Komal Shah
This patch fixes the duplicate exports of string library functions.
Signed-off-by: Komal Shah <komal_shah802003@yahoo.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
The ARM EABI defines new names for GCC helper functions.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Unfortunately, later gcc versions error out when our get_user is passed
a const pointer, since we write to a temporary variable declared as
typeof(*(p)) which propagates the const-ness.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
Noticed by Woody Suwalski <woodys@xandros.com>.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
The items in the export table do not need to be
exported elsehwere, so quash the sparse warning
by making the symbol for the table entry static.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Todd Poynor
Fix module versioning for 3 ARM symbols that do not have CRCs added,
avoid "disagrees about version of symbol struct_module" errors at module
load time. From David Singleton.
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
Those are big, slow and generally not recommended for kernel code.
They are even not present on i386. So it should be concluded that
one could as well get away with do_div() alone.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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!
