LXR linux/arch/Kconfig

   1#
   2# General architecture dependent options
   3#
   4
   5config OPROFILE
   6        tristate "OProfile system profiling"
   7        depends on PROFILING
   8        depends on HAVE_OPROFILE
   9        select RING_BUFFER
  10        select RING_BUFFER_ALLOW_SWAP
  11        help
  12          OProfile is a profiling system capable of profiling the
  13          whole system, include the kernel, kernel modules, libraries,
  14          and applications.
  15
  16          If unsure, say N.
  17
  18config OPROFILE_EVENT_MULTIPLEX
  19        bool "OProfile multiplexing support (EXPERIMENTAL)"
  20        default n
  21        depends on OPROFILE && X86
  22        help
  23          The number of hardware counters is limited. The multiplexing
  24          feature enables OProfile to gather more events than counters
  25          are provided by the hardware. This is realized by switching
  26          between events at an user specified time interval.
  27
  28          If unsure, say N.
  29
  30config HAVE_OPROFILE
  31        bool
  32
  33config KPROBES
  34        bool "Kprobes"
  35        depends on MODULES
  36        depends on HAVE_KPROBES
  37        select KALLSYMS
  38        help
  39          Kprobes allows you to trap at almost any kernel address and
  40          execute a callback function.  register_kprobe() establishes
  41          a probepoint and specifies the callback.  Kprobes is useful
  42          for kernel debugging, non-intrusive instrumentation and testing.
  43          If in doubt, say "N".
  44
  45config JUMP_LABEL
  46       bool "Optimize trace point call sites"
  47       depends on HAVE_ARCH_JUMP_LABEL
  48       help
  49         If it is detected that the compiler has support for "asm goto",
  50         the kernel will compile trace point locations with just a
  51         nop instruction. When trace points are enabled, the nop will
  52         be converted to a jump to the trace function. This technique
  53         lowers overhead and stress on the branch prediction of the
  54         processor.
  55
  56         On i386, options added to the compiler flags may increase
  57         the size of the kernel slightly.
  58
  59config OPTPROBES
  60        def_bool y
  61        depends on KPROBES && HAVE_OPTPROBES
  62        depends on !PREEMPT
  63
  64config HAVE_EFFICIENT_UNALIGNED_ACCESS
  65        bool
  66        help
  67          Some architectures are unable to perform unaligned accesses
  68          without the use of get_unaligned/put_unaligned. Others are
  69          unable to perform such accesses efficiently (e.g. trap on
  70          unaligned access and require fixing it up in the exception
  71          handler.)
  72
  73          This symbol should be selected by an architecture if it can
  74          perform unaligned accesses efficiently to allow different
  75          code paths to be selected for these cases. Some network
  76          drivers, for example, could opt to not fix up alignment
  77          problems with received packets if doing so would not help
  78          much.
  79
  80          See Documentation/unaligned-memory-access.txt for more
  81          information on the topic of unaligned memory accesses.
  82
  83config HAVE_SYSCALL_WRAPPERS
  84        bool
  85
  86config KRETPROBES
  87        def_bool y
  88        depends on KPROBES && HAVE_KRETPROBES
  89
  90config USER_RETURN_NOTIFIER
  91        bool
  92        depends on HAVE_USER_RETURN_NOTIFIER
  93        help
  94          Provide a kernel-internal notification when a cpu is about to
  95          switch to user mode.
  96
  97config HAVE_IOREMAP_PROT
  98        bool
  99
 100config HAVE_KPROBES
 101        bool
 102
 103config HAVE_KRETPROBES
 104        bool
 105
 106config HAVE_OPTPROBES
 107        bool
 108#
 109# An arch should select this if it provides all these things:
 110#
 111#       task_pt_regs()          in asm/processor.h or asm/ptrace.h
 112#       arch_has_single_step()  if there is hardware single-step support
 113#       arch_has_block_step()   if there is hardware block-step support
 114#       asm/syscall.h           supplying asm-generic/syscall.h interface
 115#       linux/regset.h          user_regset interfaces
 116#       CORE_DUMP_USE_REGSET    #define'd in linux/elf.h
 117#       TIF_SYSCALL_TRACE       calls tracehook_report_syscall_{entry,exit}
 118#       TIF_NOTIFY_RESUME       calls tracehook_notify_resume()
 119#       signal delivery         calls tracehook_signal_handler()
 120#
 121config HAVE_ARCH_TRACEHOOK
 122        bool
 123
 124config HAVE_DMA_ATTRS
 125        bool
 126
 127config USE_GENERIC_SMP_HELPERS
 128        bool
 129
 130config HAVE_REGS_AND_STACK_ACCESS_API
 131        bool
 132        help
 133          This symbol should be selected by an architecure if it supports
 134          the API needed to access registers and stack entries from pt_regs,
 135          declared in asm/ptrace.h
 136          For example the kprobes-based event tracer needs this API.
 137
 138config HAVE_CLK
 139        bool
 140        help
 141          The <linux/clk.h> calls support software clock gating and
 142          thus are a key power management tool on many systems.
 143
 144config HAVE_DMA_API_DEBUG
 145        bool
 146
 147config HAVE_DEFAULT_NO_SPIN_MUTEXES
 148        bool
 149
 150config HAVE_HW_BREAKPOINT
 151        bool
 152        depends on PERF_EVENTS
 153
 154config HAVE_MIXED_BREAKPOINTS_REGS
 155        bool
 156        depends on HAVE_HW_BREAKPOINT
 157        help
 158          Depending on the arch implementation of hardware breakpoints,
 159          some of them have separate registers for data and instruction
 160          breakpoints addresses, others have mixed registers to store
 161          them but define the access type in a control register.
 162          Select this option if your arch implements breakpoints under the
 163          latter fashion.
 164
 165config HAVE_USER_RETURN_NOTIFIER
 166        bool
 167
 168config HAVE_PERF_EVENTS_NMI
 169        bool
 170        help
 171          System hardware can generate an NMI using the perf event
 172          subsystem.  Also has support for calculating CPU cycle events
 173          to determine how many clock cycles in a given period.
 174
 175config HAVE_ARCH_JUMP_LABEL
 176        bool
 177
 178config HAVE_ARCH_MUTEX_CPU_RELAX
 179        bool
 180
 181source "kernel/gcov/Kconfig"
 182