2005-04-17 05:20:36 +07:00
|
|
|
#
|
|
|
|
# Makefile for some libs needed in the kernel.
|
|
|
|
#
|
|
|
|
|
2008-10-07 06:06:12 +07:00
|
|
|
ifdef CONFIG_FUNCTION_TRACER
|
2008-07-17 22:40:48 +07:00
|
|
|
ORIG_CFLAGS := $(KBUILD_CFLAGS)
|
|
|
|
KBUILD_CFLAGS = $(subst -pg,,$(ORIG_CFLAGS))
|
|
|
|
endif
|
|
|
|
|
2007-10-07 14:24:34 +07:00
|
|
|
lib-y := ctype.o string.o vsprintf.o cmdline.o \
|
2010-12-10 03:02:18 +07:00
|
|
|
rbtree.o radix-tree.o dump_stack.o timerqueue.o\
|
2013-05-23 12:46:09 +07:00
|
|
|
idr.o int_sqrt.o extable.o \
|
2011-08-04 09:45:10 +07:00
|
|
|
sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
|
2012-05-24 23:59:10 +07:00
|
|
|
proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
|
2012-12-15 01:03:23 +07:00
|
|
|
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
|
2013-06-01 05:26:45 +07:00
|
|
|
earlycpio.o percpu-refcount.o
|
[PATCH] Add initial implementation of klist helpers.
This klist interface provides a couple of structures that wrap around
struct list_head to provide explicit list "head" (struct klist) and
list "node" (struct klist_node) objects. For struct klist, a spinlock
is included that protects access to the actual list itself. struct
klist_node provides a pointer to the klist that owns it and a kref
reference count that indicates the number of current users of that node
in the list.
The entire point is to provide an interface for iterating over a list
that is safe and allows for modification of the list during the
iteration (e.g. insertion and removal), including modification of the
current node on the list.
It works using a 3rd object type - struct klist_iter - that is declared
and initialized before an iteration. klist_next() is used to acquire the
next element in the list. It returns NULL if there are no more items.
This klist interface provides a couple of structures that wrap around
struct list_head to provide explicit list "head" (struct klist) and
list "node" (struct klist_node) objects. For struct klist, a spinlock
is included that protects access to the actual list itself. struct
klist_node provides a pointer to the klist that owns it and a kref
reference count that indicates the number of current users of that node
in the list.
The entire point is to provide an interface for iterating over a list
that is safe and allows for modification of the list during the
iteration (e.g. insertion and removal), including modification of the
current node on the list.
It works using a 3rd object type - struct klist_iter - that is declared
and initialized before an iteration. klist_next() is used to acquire the
next element in the list. It returns NULL if there are no more items.
Internally, that routine takes the klist's lock, decrements the reference
count of the previous klist_node and increments the count of the next
klist_node. It then drops the lock and returns.
There are primitives for adding and removing nodes to/from a klist.
When deleting, klist_del() will simply decrement the reference count.
Only when the count goes to 0 is the node removed from the list.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).
Internally, that routine takes the klist's lock, decrements the reference
count of the previous klist_node and increments the count of the next
klist_node. It then drops the lock and returns.
There are primitives for adding and removing nodes to/from a klist.
When deleting, klist_del() will simply decrement the reference count.
Only when the count goes to 0 is the node removed from the list.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).
Signed-off-by: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff -Nru a/include/linux/klist.h b/include/linux/klist.h
2005-03-22 02:45:16 +07:00
|
|
|
|
2013-05-01 05:28:42 +07:00
|
|
|
obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
|
2006-10-01 13:29:12 +07:00
|
|
|
lib-$(CONFIG_MMU) += ioremap.o
|
2006-03-25 18:08:08 +07:00
|
|
|
lib-$(CONFIG_SMP) += cpumask.o
|
|
|
|
|
2011-12-13 16:36:20 +07:00
|
|
|
lib-y += kobject.o klist.o
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-07-24 11:30:37 +07:00
|
|
|
obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
|
2008-08-31 22:13:54 +07:00
|
|
|
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
|
2013-07-09 06:01:43 +07:00
|
|
|
gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
|
2013-02-28 08:05:50 +07:00
|
|
|
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o
|
2013-05-01 05:27:30 +07:00
|
|
|
obj-y += string_helpers.o
|
|
|
|
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
|
2011-03-23 06:34:40 +07:00
|
|
|
obj-y += kstrtox.o
|
|
|
|
obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
ifeq ($(CONFIG_DEBUG_KOBJECT),y)
|
|
|
|
CFLAGS_kobject.o += -DDEBUG
|
|
|
|
CFLAGS_kobject_uevent.o += -DDEBUG
|
|
|
|
endif
|
|
|
|
|
2007-02-11 22:41:31 +07:00
|
|
|
obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
|
2011-11-25 01:45:20 +07:00
|
|
|
obj-$(CONFIG_GENERIC_PCI_IOMAP) += pci_iomap.o
|
2007-08-23 04:01:36 +07:00
|
|
|
obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o
|
|
|
|
obj-$(CONFIG_CHECK_SIGNATURE) += check_signature.o
|
2006-07-03 14:24:48 +07:00
|
|
|
obj-$(CONFIG_DEBUG_LOCKING_API_SELFTESTS) += locking-selftest.o
|
[PATCH] spinlock consolidation
This patch (written by me and also containing many suggestions of Arjan van
de Ven) does a major cleanup of the spinlock code. It does the following
things:
- consolidates and enhances the spinlock/rwlock debugging code
- simplifies the asm/spinlock.h files
- encapsulates the raw spinlock type and moves generic spinlock
features (such as ->break_lock) into the generic code.
- cleans up the spinlock code hierarchy to get rid of the spaghetti.
Most notably there's now only a single variant of the debugging code,
located in lib/spinlock_debug.c. (previously we had one SMP debugging
variant per architecture, plus a separate generic one for UP builds)
Also, i've enhanced the rwlock debugging facility, it will now track
write-owners. There is new spinlock-owner/CPU-tracking on SMP builds too.
All locks have lockup detection now, which will work for both soft and hard
spin/rwlock lockups.
The arch-level include files now only contain the minimally necessary
subset of the spinlock code - all the rest that can be generalized now
lives in the generic headers:
include/asm-i386/spinlock_types.h | 16
include/asm-x86_64/spinlock_types.h | 16
I have also split up the various spinlock variants into separate files,
making it easier to see which does what. The new layout is:
SMP | UP
----------------------------|-----------------------------------
asm/spinlock_types_smp.h | linux/spinlock_types_up.h
linux/spinlock_types.h | linux/spinlock_types.h
asm/spinlock_smp.h | linux/spinlock_up.h
linux/spinlock_api_smp.h | linux/spinlock_api_up.h
linux/spinlock.h | linux/spinlock.h
/*
* here's the role of the various spinlock/rwlock related include files:
*
* on SMP builds:
*
* asm/spinlock_types.h: contains the raw_spinlock_t/raw_rwlock_t and the
* initializers
*
* linux/spinlock_types.h:
* defines the generic type and initializers
*
* asm/spinlock.h: contains the __raw_spin_*()/etc. lowlevel
* implementations, mostly inline assembly code
*
* (also included on UP-debug builds:)
*
* linux/spinlock_api_smp.h:
* contains the prototypes for the _spin_*() APIs.
*
* linux/spinlock.h: builds the final spin_*() APIs.
*
* on UP builds:
*
* linux/spinlock_type_up.h:
* contains the generic, simplified UP spinlock type.
* (which is an empty structure on non-debug builds)
*
* linux/spinlock_types.h:
* defines the generic type and initializers
*
* linux/spinlock_up.h:
* contains the __raw_spin_*()/etc. version of UP
* builds. (which are NOPs on non-debug, non-preempt
* builds)
*
* (included on UP-non-debug builds:)
*
* linux/spinlock_api_up.h:
* builds the _spin_*() APIs.
*
* linux/spinlock.h: builds the final spin_*() APIs.
*/
All SMP and UP architectures are converted by this patch.
arm, i386, ia64, ppc, ppc64, s390/s390x, x64 was build-tested via
crosscompilers. m32r, mips, sh, sparc, have not been tested yet, but should
be mostly fine.
From: Grant Grundler <grundler@parisc-linux.org>
Booted and lightly tested on a500-44 (64-bit, SMP kernel, dual CPU).
Builds 32-bit SMP kernel (not booted or tested). I did not try to build
non-SMP kernels. That should be trivial to fix up later if necessary.
I converted bit ops atomic_hash lock to raw_spinlock_t. Doing so avoids
some ugly nesting of linux/*.h and asm/*.h files. Those particular locks
are well tested and contained entirely inside arch specific code. I do NOT
expect any new issues to arise with them.
If someone does ever need to use debug/metrics with them, then they will
need to unravel this hairball between spinlocks, atomic ops, and bit ops
that exist only because parisc has exactly one atomic instruction: LDCW
(load and clear word).
From: "Luck, Tony" <tony.luck@intel.com>
ia64 fix
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Arjan van de Ven <arjanv@infradead.org>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Cc: Matthew Wilcox <willy@debian.org>
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Mikael Pettersson <mikpe@csd.uu.se>
Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10 14:25:56 +07:00
|
|
|
obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock_debug.o
|
2005-04-17 05:20:36 +07:00
|
|
|
lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
|
|
|
|
lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
|
2012-12-18 07:01:39 +07:00
|
|
|
lib-$(CONFIG_PERCPU_RWSEM) += percpu-rwsem.o
|
2010-03-05 23:34:46 +07:00
|
|
|
|
|
|
|
CFLAGS_hweight.o = $(subst $(quote),,$(CONFIG_ARCH_HWEIGHT_CFLAGS))
|
2006-12-07 11:39:16 +07:00
|
|
|
obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o
|
2010-03-05 23:34:46 +07:00
|
|
|
|
2009-11-21 02:13:39 +07:00
|
|
|
obj-$(CONFIG_BTREE) += btree.o
|
2005-06-22 07:14:34 +07:00
|
|
|
obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
|
2006-09-29 15:59:00 +07:00
|
|
|
obj-$(CONFIG_DEBUG_LIST) += list_debug.o
|
2008-04-30 14:55:01 +07:00
|
|
|
obj-$(CONFIG_DEBUG_OBJECTS) += debugobjects.o
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-08-17 18:17:26 +07:00
|
|
|
ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
|
2005-04-17 05:20:36 +07:00
|
|
|
lib-y += dec_and_lock.o
|
|
|
|
endif
|
|
|
|
|
2006-12-08 17:36:25 +07:00
|
|
|
obj-$(CONFIG_BITREVERSE) += bitrev.o
|
2009-06-11 20:51:15 +07:00
|
|
|
obj-$(CONFIG_RATIONAL) += rational.o
|
2005-04-17 05:20:36 +07:00
|
|
|
obj-$(CONFIG_CRC_CCITT) += crc-ccitt.o
|
2005-08-17 18:17:26 +07:00
|
|
|
obj-$(CONFIG_CRC16) += crc16.o
|
2008-06-25 22:22:42 +07:00
|
|
|
obj-$(CONFIG_CRC_T10DIF)+= crc-t10dif.o
|
2006-06-12 21:17:04 +07:00
|
|
|
obj-$(CONFIG_CRC_ITU_T) += crc-itu-t.o
|
2005-04-17 05:20:36 +07:00
|
|
|
obj-$(CONFIG_CRC32) += crc32.o
|
2007-07-17 18:04:03 +07:00
|
|
|
obj-$(CONFIG_CRC7) += crc7.o
|
2005-04-17 05:20:36 +07:00
|
|
|
obj-$(CONFIG_LIBCRC32C) += libcrc32c.o
|
2011-05-31 16:22:15 +07:00
|
|
|
obj-$(CONFIG_CRC8) += crc8.o
|
2005-06-22 07:15:02 +07:00
|
|
|
obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
|
|
|
|
obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/
|
|
|
|
obj-$(CONFIG_REED_SOLOMON) += reed_solomon/
|
lib: add shared BCH ECC library
This is a new software BCH encoding/decoding library, similar to the shared
Reed-Solomon library.
Binary BCH (Bose-Chaudhuri-Hocquenghem) codes are widely used to correct
errors in NAND flash devices requiring more than 1-bit ecc correction; they
are generally better suited for NAND flash than RS codes because NAND bit
errors do not occur in bursts. Latest SLC NAND devices typically require at
least 4-bit ecc protection per 512 bytes block.
This library provides software encoding/decoding, but may also be used with
ASIC/SoC hardware BCH engines to perform error correction. It is being
currently used for this purpose on an OMAP3630 board (4bit/8bit HW BCH). It
has also been used to decode raw dumps of NAND devices with on-die BCH ecc
engines (e.g. Micron 4bit ecc SLC devices).
Latest NAND devices (including SLC) can exhibit high error rates (typically
a dozen or more bitflips per hour during stress tests); in order to
minimize the performance impact of error correction, this library
implements recently developed algorithms for fast polynomial root finding
(see bch.c header for details) instead of the traditional exhaustive Chien
root search; a few performance figures are provided below:
Platform: arm926ejs @ 468 MHz, 32 KiB icache, 16 KiB dcache
BCH ecc : 4-bit per 512 bytes
Encoding average throughput: 250 Mbits/s
Error correction time (compared with Chien search):
average worst average (Chien) worst (Chien)
----------------------------------------------------------
1 bit 8.5 µs 11 µs 200 µs 383 µs
2 bit 9.7 µs 12.5 µs 477 µs 728 µs
3 bit 18.1 µs 20.6 µs 758 µs 1010 µs
4 bit 19.5 µs 23 µs 1028 µs 1280 µs
In the above figures, "worst" is meant in terms of error pattern, not in
terms of cache miss / page faults effects (not taken into account here).
The library has been extensively tested on the following platforms: x86,
x86_64, arm926ejs, omap3630, qemu-ppc64, qemu-mips.
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-03-11 17:05:32 +07:00
|
|
|
obj-$(CONFIG_BCH) += bch.o
|
2007-07-11 07:22:24 +07:00
|
|
|
obj-$(CONFIG_LZO_COMPRESS) += lzo/
|
|
|
|
obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
|
2013-07-09 06:01:49 +07:00
|
|
|
obj-$(CONFIG_LZ4_COMPRESS) += lz4/
|
|
|
|
obj-$(CONFIG_LZ4HC_COMPRESS) += lz4/
|
2013-07-09 06:01:46 +07:00
|
|
|
obj-$(CONFIG_LZ4_DECOMPRESS) += lz4/
|
2011-01-13 08:01:22 +07:00
|
|
|
obj-$(CONFIG_XZ_DEC) += xz/
|
2009-07-13 17:35:12 +07:00
|
|
|
obj-$(CONFIG_RAID6_PQ) += raid6/
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-01-09 06:14:17 +07:00
|
|
|
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
|
|
|
|
lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
|
|
|
|
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
|
decompressors: add boot-time XZ support
This implements the API defined in <linux/decompress/generic.h> which is
used for kernel, initramfs, and initrd decompression. This patch together
with the first patch is enough for XZ-compressed initramfs and initrd;
XZ-compressed kernel will need arch-specific changes.
The buffering requirements described in decompress_unxz.c are stricter
than with gzip, so the relevant changes should be done to the
arch-specific code when adding support for XZ-compressed kernel.
Similarly, the heap size in arch-specific pre-boot code may need to be
increased (30 KiB is enough).
The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and
memzero() (memset(ptr, 0, size)), which aren't available in all
arch-specific pre-boot environments. I'm including simple versions in
decompress_unxz.c, but a cleaner solution would naturally be nicer.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alain Knaff <alain@knaff.lu>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-01-13 08:01:23 +07:00
|
|
|
lib-$(CONFIG_DECOMPRESS_XZ) += decompress_unxz.o
|
2010-01-09 05:42:46 +07:00
|
|
|
lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
|
2013-07-09 06:01:46 +07:00
|
|
|
lib-$(CONFIG_DECOMPRESS_LZ4) += decompress_unlz4.o
|
2009-01-06 04:48:31 +07:00
|
|
|
|
2005-06-24 13:49:52 +07:00
|
|
|
obj-$(CONFIG_TEXTSEARCH) += textsearch.o
|
[LIB]: Knuth-Morris-Pratt textsearch algorithm
Implements a linear-time string-matching algorithm due to Knuth,
Morris, and Pratt [1]. Their algorithm avoids the explicit
computation of the transition function DELTA altogether. Its
matching time is O(n), for n being length(text), using just an
auxiliary function PI[1..m], for m being length(pattern),
precomputed from the pattern in time O(m). The array PI allows
the transition function DELTA to be computed efficiently
"on the fly" as needed. Roughly speaking, for any state
"q" = 0,1,...,m and any character "a" in SIGMA, the value
PI["q"] contains the information that is independent of "a" and
is needed to compute DELTA("q", "a") [2]. Since the array PI
has only m entries, whereas DELTA has O(m|SIGMA|) entries, we
save a factor of |SIGMA| in the preprocessing time by computing
PI rather than DELTA.
[1] Cormen, Leiserson, Rivest, Stein
Introdcution to Algorithms, 2nd Edition, MIT Press
[2] See finite automation theory
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-24 10:58:37 +07:00
|
|
|
obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o
|
2005-08-26 06:12:22 +07:00
|
|
|
obj-$(CONFIG_TEXTSEARCH_BM) += ts_bm.o
|
2005-06-24 10:59:16 +07:00
|
|
|
obj-$(CONFIG_TEXTSEARCH_FSM) += ts_fsm.o
|
2006-06-23 16:05:40 +07:00
|
|
|
obj-$(CONFIG_SMP) += percpu_counter.o
|
2006-09-12 14:04:40 +07:00
|
|
|
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
|
2005-06-24 10:49:30 +07:00
|
|
|
|
2005-09-30 04:42:42 +07:00
|
|
|
obj-$(CONFIG_SWIOTLB) += swiotlb.o
|
2008-02-05 13:28:07 +07:00
|
|
|
obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
|
2006-12-08 17:39:43 +07:00
|
|
|
obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
|
2012-07-31 04:43:02 +07:00
|
|
|
obj-$(CONFIG_NOTIFIER_ERROR_INJECTION) += notifier-error-inject.o
|
2010-05-27 04:43:36 +07:00
|
|
|
obj-$(CONFIG_CPU_NOTIFIER_ERROR_INJECT) += cpu-notifier-error-inject.o
|
2012-07-31 04:43:07 +07:00
|
|
|
obj-$(CONFIG_PM_NOTIFIER_ERROR_INJECT) += pm-notifier-error-inject.o
|
2012-07-31 04:43:10 +07:00
|
|
|
obj-$(CONFIG_MEMORY_NOTIFIER_ERROR_INJECT) += memory-notifier-error-inject.o
|
2012-12-14 06:32:52 +07:00
|
|
|
obj-$(CONFIG_OF_RECONFIG_NOTIFIER_ERROR_INJECT) += \
|
|
|
|
of-reconfig-notifier-error-inject.o
|
2005-09-30 04:42:42 +07:00
|
|
|
|
[PATCH] Generic BUG implementation
This patch adds common handling for kernel BUGs, for use by architectures as
they wish. The code is derived from arch/powerpc.
The advantages of having common BUG handling are:
- consistent BUG reporting across architectures
- shared implementation of out-of-line file/line data
- implement CONFIG_DEBUG_BUGVERBOSE consistently
This means that in inline impact of BUG is just the illegal instruction
itself, which is an improvement for i386 and x86-64.
A BUG is represented in the instruction stream as an illegal instruction,
which has file/line information associated with it. This extra information is
stored in the __bug_table section in the ELF file.
When the kernel gets an illegal instruction, it first confirms it might
possibly be from a BUG (ie, in kernel mode, the right illegal instruction).
It then calls report_bug(). This searches __bug_table for a matching
instruction pointer, and if found, prints the corresponding file/line
information. If report_bug() determines that it wasn't a BUG which caused the
trap, it returns BUG_TRAP_TYPE_NONE.
Some architectures (powerpc) implement WARN using the same mechanism; if the
illegal instruction was the result of a WARN, then report_bug(Q) returns
CONFIG_DEBUG_BUGVERBOSE; otherwise it returns BUG_TRAP_TYPE_BUG.
lib/bug.c keeps a list of loaded modules which can be searched for __bug_table
entries. The architecture must call
module_bug_finalize()/module_bug_cleanup() from its corresponding
module_finalize/cleanup functions.
Unsetting CONFIG_DEBUG_BUGVERBOSE will reduce the kernel size by some amount.
At the very least, filename and line information will not be recorded for each
but, but architectures may decide to store no extra information per BUG at
all.
Unfortunately, gcc doesn't have a general way to mark an asm() as noreturn, so
architectures will generally have to include an infinite loop (or similar) in
the BUG code, so that gcc knows execution won't continue beyond that point.
gcc does have a __builtin_trap() operator which may be useful to achieve the
same effect, unfortunately it cannot be used to actually implement the BUG
itself, because there's no way to get the instruction's address for use in
generating the __bug_table entry.
[randy.dunlap@oracle.com: Handle BUG=n, GENERIC_BUG=n to prevent build errors]
[bunk@stusta.de: include/linux/bug.h must always #include <linux/module.h]
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andi Kleen <ak@muc.de>
Cc: Hugh Dickens <hugh@veritas.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08 17:36:19 +07:00
|
|
|
lib-$(CONFIG_GENERIC_BUG) += bug.o
|
|
|
|
|
2008-07-26 09:45:59 +07:00
|
|
|
obj-$(CONFIG_HAVE_ARCH_TRACEHOOK) += syscall.o
|
|
|
|
|
2009-02-05 23:51:38 +07:00
|
|
|
obj-$(CONFIG_DYNAMIC_DEBUG) += dynamic_debug.o
|
driver core: basic infrastructure for per-module dynamic debug messages
Base infrastructure to enable per-module debug messages.
I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
control of debugging statements on a per-module basis in one /proc file,
currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
is not set, debugging statements can still be enabled as before, often by
defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.
The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
can be dynamically enabled/disabled on a per-module basis.
Future plans include extending this functionality to subsystems, that define
their own debug levels and flags.
Usage:
Dynamic debugging is controlled by the debugfs file,
<debugfs>/dynamic_printk/modules. This file contains a list of the modules that
can be enabled. The format of the file is as follows:
<module_name> <enabled=0/1>
.
.
.
<module_name> : Name of the module in which the debug call resides
<enabled=0/1> : whether the messages are enabled or not
For example:
snd_hda_intel enabled=0
fixup enabled=1
driver enabled=0
Enable a module:
$echo "set enabled=1 <module_name>" > dynamic_printk/modules
Disable a module:
$echo "set enabled=0 <module_name>" > dynamic_printk/modules
Enable all modules:
$echo "set enabled=1 all" > dynamic_printk/modules
Disable all modules:
$echo "set enabled=0 all" > dynamic_printk/modules
Finally, passing "dynamic_printk" at the command line enables
debugging for all modules. This mode can be turned off via the above
disable command.
[gkh: minor cleanups and tweaks to make the build work quietly]
Signed-off-by: Jason Baron <jbaron@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-13 03:46:19 +07:00
|
|
|
|
2009-03-04 13:53:30 +07:00
|
|
|
obj-$(CONFIG_NLATTR) += nlattr.o
|
driver core: basic infrastructure for per-module dynamic debug messages
Base infrastructure to enable per-module debug messages.
I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
control of debugging statements on a per-module basis in one /proc file,
currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
is not set, debugging statements can still be enabled as before, often by
defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.
The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
can be dynamically enabled/disabled on a per-module basis.
Future plans include extending this functionality to subsystems, that define
their own debug levels and flags.
Usage:
Dynamic debugging is controlled by the debugfs file,
<debugfs>/dynamic_printk/modules. This file contains a list of the modules that
can be enabled. The format of the file is as follows:
<module_name> <enabled=0/1>
.
.
.
<module_name> : Name of the module in which the debug call resides
<enabled=0/1> : whether the messages are enabled or not
For example:
snd_hda_intel enabled=0
fixup enabled=1
driver enabled=0
Enable a module:
$echo "set enabled=1 <module_name>" > dynamic_printk/modules
Disable a module:
$echo "set enabled=0 <module_name>" > dynamic_printk/modules
Enable all modules:
$echo "set enabled=1 all" > dynamic_printk/modules
Disable all modules:
$echo "set enabled=0 all" > dynamic_printk/modules
Finally, passing "dynamic_printk" at the command line enables
debugging for all modules. This mode can be turned off via the above
disable command.
[gkh: minor cleanups and tweaks to make the build work quietly]
Signed-off-by: Jason Baron <jbaron@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-13 03:46:19 +07:00
|
|
|
|
2009-09-26 06:07:19 +07:00
|
|
|
obj-$(CONFIG_LRU_CACHE) += lru_cache.o
|
|
|
|
|
2009-01-09 18:19:52 +07:00
|
|
|
obj-$(CONFIG_DMA_API_DEBUG) += dma-debug.o
|
|
|
|
|
2009-05-14 05:56:38 +07:00
|
|
|
obj-$(CONFIG_GENERIC_CSUM) += checksum.o
|
|
|
|
|
2009-06-13 04:10:05 +07:00
|
|
|
obj-$(CONFIG_GENERIC_ATOMIC64) += atomic64.o
|
|
|
|
|
2010-02-24 16:54:24 +07:00
|
|
|
obj-$(CONFIG_ATOMIC64_SELFTEST) += atomic64_test.o
|
|
|
|
|
2010-11-16 08:58:37 +07:00
|
|
|
obj-$(CONFIG_AVERAGE) += average.o
|
|
|
|
|
2011-01-19 18:03:25 +07:00
|
|
|
obj-$(CONFIG_CPU_RMAP) += cpu_rmap.o
|
|
|
|
|
2011-05-31 16:22:16 +07:00
|
|
|
obj-$(CONFIG_CORDIC) += cordic.o
|
|
|
|
|
dql: Dynamic queue limits
Implementation of dynamic queue limits (dql). This is a libary which
allows a queue limit to be dynamically managed. The goal of dql is
to set the queue limit, number of objects to the queue, to be minimized
without allowing the queue to be starved.
dql would be used with a queue which has these properties:
1) Objects are queued up to some limit which can be expressed as a
count of objects.
2) Periodically a completion process executes which retires consumed
objects.
3) Starvation occurs when limit has been reached, all queued data has
actually been consumed but completion processing has not yet run,
so queuing new data is blocked.
4) Minimizing the amount of queued data is desirable.
A canonical example of such a queue would be a NIC HW transmit queue.
The queue limit is dynamic, it will increase or decrease over time
depending on the workload. The queue limit is recalculated each time
completion processing is done. Increases occur when the queue is
starved and can exponentially increase over successive intervals.
Decreases occur when more data is being maintained in the queue than
needed to prevent starvation. The number of extra objects, or "slack",
is measured over successive intervals, and to avoid hysteresis the
limit is only reduced by the miminum slack seen over a configurable
time period.
dql API provides routines to manage the queue:
- dql_init is called to intialize the dql structure
- dql_reset is called to reset dynamic values
- dql_queued called when objects are being enqueued
- dql_avail returns availability in the queue
- dql_completed is called when objects have be consumed in the queue
Configuration consists of:
- max_limit, maximum limit
- min_limit, minimum limit
- slack_hold_time, time to measure instances of slack before reducing
queue limit
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-28 23:32:35 +07:00
|
|
|
obj-$(CONFIG_DQL) += dynamic_queue_limits.o
|
|
|
|
|
2011-08-31 18:05:16 +07:00
|
|
|
obj-$(CONFIG_MPILIB) += mpi/
|
2012-01-17 22:12:03 +07:00
|
|
|
obj-$(CONFIG_SIGNATURE) += digsig.o
|
2011-08-31 18:05:16 +07:00
|
|
|
|
2012-02-02 05:17:54 +07:00
|
|
|
obj-$(CONFIG_CLZ_TAB) += clz_tab.o
|
|
|
|
|
2012-04-27 19:24:03 +07:00
|
|
|
obj-$(CONFIG_DDR) += jedec_ddr_data.o
|
|
|
|
|
2012-05-25 03:12:28 +07:00
|
|
|
obj-$(CONFIG_GENERIC_STRNCPY_FROM_USER) += strncpy_from_user.o
|
2012-05-27 01:06:38 +07:00
|
|
|
obj-$(CONFIG_GENERIC_STRNLEN_USER) += strnlen_user.o
|
2012-05-25 03:12:28 +07:00
|
|
|
|
2013-06-04 23:46:26 +07:00
|
|
|
obj-$(CONFIG_GENERIC_NET_UTILS) += net_utils.o
|
|
|
|
|
lib: add support for stmp-style devices
MX23/28 use IP cores which follow a register layout I have first seen on
STMP3xxx SoCs. In this layout, every register actually has four u32:
1.) to store a value directly
2.) a SET register where every 1-bit sets the corresponding bit,
others are unaffected
3.) same with a CLR register
4.) same with a TOG (toggle) register
Also, the 2 MSBs in register 0 are always the same and can be used to reset
the IP core.
All this is strictly speaking not mach-specific (but IP core specific) and,
thus, doesn't need to be in mach-mxs/include. At least mx6 also uses IP cores
following this stmp-style. So:
Introduce a stmp-style device, put the code and defines for that in a public
place (lib/), and let drivers for stmp-style devices select that code.
To avoid regressions and ease reviewing, the actual code is simply copied from
mach-mxs. It definately wants updates, but those need a seperate patch series.
Voila, mach dependency gone, reusable code introduced. Note that I didn't
remove the duplicated code from mach-mxs yet, first the drivers have to be
converted.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
2011-09-01 01:35:40 +07:00
|
|
|
obj-$(CONFIG_STMP_DEVICE) += stmp_device.o
|
|
|
|
|
2012-07-05 23:12:38 +07:00
|
|
|
libfdt_files = fdt.o fdt_ro.o fdt_wip.o fdt_rw.o fdt_sw.o fdt_strerror.o
|
|
|
|
$(foreach file, $(libfdt_files), \
|
|
|
|
$(eval CFLAGS_$(file) = -I$(src)/../scripts/dtc/libfdt))
|
|
|
|
lib-$(CONFIG_LIBFDT) += $(libfdt_files)
|
|
|
|
|
2012-10-09 06:30:39 +07:00
|
|
|
obj-$(CONFIG_RBTREE_TEST) += rbtree_test.o
|
rbtree: add prio tree and interval tree tests
Patch 1 implements support for interval trees, on top of the augmented
rbtree API. It also adds synthetic tests to compare the performance of
interval trees vs prio trees. Short answers is that interval trees are
slightly faster (~25%) on insert/erase, and much faster (~2.4 - 3x)
on search. It is debatable how realistic the synthetic test is, and I have
not made such measurements yet, but my impression is that interval trees
would still come out faster.
Patch 2 uses a preprocessor template to make the interval tree generic,
and uses it as a replacement for the vma prio_tree.
Patch 3 takes the other prio_tree user, kmemleak, and converts it to use
a basic rbtree. We don't actually need the augmented rbtree support here
because the intervals are always non-overlapping.
Patch 4 removes the now-unused prio tree library.
Patch 5 proposes an additional optimization to rb_erase_augmented, now
providing it as an inline function so that the augmented callbacks can be
inlined in. This provides an additional 5-10% performance improvement
for the interval tree insert/erase benchmark. There is a maintainance cost
as it exposes augmented rbtree users to some of the rbtree library internals;
however I think this cost shouldn't be too high as I expect the augmented
rbtree will always have much less users than the base rbtree.
I should probably add a quick summary of why I think it makes sense to
replace prio trees with augmented rbtree based interval trees now. One of
the drivers is that we need augmented rbtrees for Rik's vma gap finding
code, and once you have them, it just makes sense to use them for interval
trees as well, as this is the simpler and more well known algorithm. prio
trees, in comparison, seem *too* clever: they impose an additional 'heap'
constraint on the tree, which they use to guarantee a faster worst-case
complexity of O(k+log N) for stabbing queries in a well-balanced prio
tree, vs O(k*log N) for interval trees (where k=number of matches,
N=number of intervals). Now this sounds great, but in practice prio trees
don't realize this theorical benefit. First, the additional constraint
makes them harder to update, so that the kernel implementation has to
simplify things by balancing them like a radix tree, which is not always
ideal. Second, the fact that there are both index and heap properties
makes both tree manipulation and search more complex, which results in a
higher multiplicative time constant. As it turns out, the simple interval
tree algorithm ends up running faster than the more clever prio tree.
This patch:
Add two test modules:
- prio_tree_test measures the performance of lib/prio_tree.c, both for
insertion/removal and for stabbing searches
- interval_tree_test measures the performance of a library of equivalent
functionality, built using the augmented rbtree support.
In order to support the second test module, lib/interval_tree.c is
introduced. It is kept separate from the interval_tree_test main file
for two reasons: first we don't want to provide an unfair advantage
over prio_tree_test by having everything in a single compilation unit,
and second there is the possibility that the interval tree functionality
could get some non-test users in kernel over time.
Signed-off-by: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-09 06:31:23 +07:00
|
|
|
obj-$(CONFIG_INTERVAL_TREE_TEST) += interval_tree_test.o
|
|
|
|
|
|
|
|
interval_tree_test-objs := interval_tree_test_main.o interval_tree.o
|
2012-10-09 06:30:39 +07:00
|
|
|
|
2012-09-24 23:11:16 +07:00
|
|
|
obj-$(CONFIG_ASN1) += asn1_decoder.o
|
|
|
|
|
2013-06-09 16:46:43 +07:00
|
|
|
obj-$(CONFIG_FONT_SUPPORT) += fonts/
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
hostprogs-y := gen_crc32table
|
|
|
|
clean-files := crc32table.h
|
|
|
|
|
|
|
|
$(obj)/crc32.o: $(obj)/crc32table.h
|
|
|
|
|
|
|
|
quiet_cmd_crc32 = GEN $@
|
|
|
|
cmd_crc32 = $< > $@
|
|
|
|
|
|
|
|
$(obj)/crc32table.h: $(obj)/gen_crc32table
|
|
|
|
$(call cmd,crc32)
|
2012-09-22 05:30:46 +07:00
|
|
|
|
|
|
|
#
|
|
|
|
# Build a fast OID lookip registry from include/linux/oid_registry.h
|
|
|
|
#
|
|
|
|
obj-$(CONFIG_OID_REGISTRY) += oid_registry.o
|
|
|
|
|
2012-12-05 02:52:28 +07:00
|
|
|
$(obj)/oid_registry.o: $(obj)/oid_registry_data.c
|
2012-09-22 05:30:46 +07:00
|
|
|
|
|
|
|
$(obj)/oid_registry_data.c: $(srctree)/include/linux/oid_registry.h \
|
|
|
|
$(src)/build_OID_registry
|
|
|
|
$(call cmd,build_OID_registry)
|
|
|
|
|
|
|
|
quiet_cmd_build_OID_registry = GEN $@
|
|
|
|
cmd_build_OID_registry = perl $(srctree)/$(src)/build_OID_registry $< $@
|
|
|
|
|
|
|
|
clean-files += oid_registry_data.c
|
2013-04-16 03:09:45 +07:00
|
|
|
|
|
|
|
obj-$(CONFIG_UCS2_STRING) += ucs2_string.o
|