lkml.org 
[lkml]   [2007]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 08/11] x86: move the rest of the menu's to Kconfig
    Date
    With this patch we have all the Kconfig file shared
    between i386 and x86_64.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    ---
    arch/x86/Kconfig | 1052 ++++++++++++++++++++++++++++++++++++++++++++++
    arch/x86/Kconfig.i386 | 1053 -----------------------------------------------
    arch/x86/Kconfig.x86_64 | 490 ----------------------
    3 files changed, 1052 insertions(+), 1543 deletions(-)

    diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    index d47b5a2..34517bf 100644
    --- a/arch/x86/Kconfig
    +++ b/arch/x86/Kconfig
    @@ -151,7 +151,1059 @@ config X86_TRAMPOLINE

    config KTIME_SCALAR
    def_bool X86_32
    +source "init/Kconfig"

    +menu "Processor type and features"
    +
    +source "kernel/time/Kconfig"
    +
    +config SMP
    + bool "Symmetric multi-processing support"
    + ---help---
    + This enables support for systems with more than one CPU. If you have
    + a system with only one CPU, like most personal computers, say N. If
    + you have a system with more than one CPU, say Y.
    +
    + If you say N here, the kernel will run on single and multiprocessor
    + machines, but will use only one CPU of a multiprocessor machine. If
    + you say Y here, the kernel will run on many, but not all,
    + singleprocessor machines. On a singleprocessor machine, the kernel
    + will run faster if you say N here.
    +
    + Note that if you say Y here and choose architecture "586" or
    + "Pentium" under "Processor family", the kernel will not work on 486
    + architectures. Similarly, multiprocessor kernels for the "PPro"
    + architecture may not work on all Pentium based boards.
    +
    + People using multiprocessor machines who say Y here should also say
    + Y to "Enhanced Real Time Clock Support", below. The "Advanced Power
    + Management" code will be disabled if you say Y here.
    +
    + See also the <file:Documentation/smp.txt>,
    + <file:Documentation/i386/IO-APIC.txt>,
    + <file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO available at
    + <http://www.tldp.org/docs.html#howto>.
    +
    + If you don't know what to do here, say N.
    +
    +choice
    + prompt "Subarchitecture Type"
    + default X86_PC
    +
    +config X86_PC
    + bool "PC-compatible"
    + help
    + Choose this option if your computer is a standard PC or compatible.
    +
    +config X86_ELAN
    + bool "AMD Elan"
    + depends on X86_32
    + help
    + Select this for an AMD Elan processor.
    +
    + Do not use this option for K6/Athlon/Opteron processors!
    +
    + If unsure, choose "PC-compatible" instead.
    +
    +config X86_VOYAGER
    + bool "Voyager (NCR)"
    + depends on X86_32
    + select SMP if !BROKEN
    + help
    + Voyager is an MCA-based 32-way capable SMP architecture proprietary
    + to NCR Corp. Machine classes 345x/35xx/4100/51xx are Voyager-based.
    +
    + *** WARNING ***
    +
    + If you do not specifically know you have a Voyager based machine,
    + say N here, otherwise the kernel you build will not be bootable.
    +
    +config X86_NUMAQ
    + bool "NUMAQ (IBM/Sequent)"
    + select SMP
    + select NUMA
    + depends on X86_32
    + help
    + This option is used for getting Linux to run on a (IBM/Sequent) NUMA
    + multiquad box. This changes the way that processors are bootstrapped,
    + and uses Clustered Logical APIC addressing mode instead of Flat Logical.
    + You will need a new lynxer.elf file to flash your firmware with - send
    + email to <Martin.Bligh@us.ibm.com>.
    +
    +config X86_SUMMIT
    + bool "Summit/EXA (IBM x440)"
    + depends on X86_32 && SMP
    + help
    + This option is needed for IBM systems that use the Summit/EXA chipset.
    + In particular, it is needed for the x440.
    +
    + If you don't have one of these computers, you should say N here.
    + If you want to build a NUMA kernel, you must select ACPI.
    +
    +config X86_BIGSMP
    + bool "Support for other sub-arch SMP systems with more than 8 CPUs"
    + depends on X86_32 && SMP
    + help
    + This option is needed for the systems that have more than 8 CPUs
    + and if the system is not of any sub-arch type above.
    +
    + If you don't have such a system, you should say N here.
    +
    +config X86_VISWS
    + bool "SGI 320/540 (Visual Workstation)"
    + depends on X86_32
    + help
    + The SGI Visual Workstation series is an IA32-based workstation
    + based on SGI systems chips with some legacy PC hardware attached.
    +
    + Say Y here to create a kernel to run on the SGI 320 or 540.
    +
    + A kernel compiled for the Visual Workstation will not run on PCs
    + and vice versa. See <file:Documentation/sgi-visws.txt> for details.
    +
    +config X86_GENERICARCH
    + bool "Generic architecture (Summit, bigsmp, ES7000, default)"
    + depends on X86_32
    + help
    + This option compiles in the Summit, bigsmp, ES7000, default subarchitectures.
    + It is intended for a generic binary kernel.
    + If you want a NUMA kernel, select ACPI. We need SRAT for NUMA.
    +
    +config X86_ES7000
    + bool "Support for Unisys ES7000 IA32 series"
    + depends on X86_32 && SMP
    + help
    + Support for Unisys ES7000 systems. Say 'Y' here if this kernel is
    + supposed to run on an IA32-based Unisys ES7000 system.
    + Only choose this option if you have such a system, otherwise you
    + should say N here.
    +
    +config X86_VSMP
    + bool "Support for ScaleMP vSMP"
    + depends on X86_64 && PCI
    + help
    + Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
    + supposed to run on these EM64T-based machines. Only choose this option
    + if you have one of these machines.
    +
    +endchoice
    +
    +config SCHED_NO_NO_OMIT_FRAME_POINTER
    + bool "Single-depth WCHAN output"
    + default y
    + depends on X86_32
    + help
    + Calculate simpler /proc/<PID>/wchan values. If this option
    + is disabled then wchan values will recurse back to the
    + caller function. This provides more accurate wchan values,
    + at the expense of slightly more scheduling overhead.
    +
    + If in doubt, say "Y".
    +
    +config PARAVIRT
    + bool
    + depends on X86_32 && !(X86_VISWS || X86_VOYAGER)
    + help
    + This changes the kernel so it can modify itself when it is run
    + under a hypervisor, potentially improving performance significantly
    + over full virtualization. However, when run without a hypervisor
    + the kernel is theoretically slower and slightly larger.
    +
    +menuconfig PARAVIRT_GUEST
    + bool "Paravirtualized guest support"
    + depends on X86_32
    + help
    + Say Y here to get to see options related to running Linux under
    + various hypervisors. This option alone does not add any kernel code.
    +
    + If you say N, all options in this submenu will be skipped and disabled.
    +
    +if PARAVIRT_GUEST
    +
    +source "arch/x86/xen/Kconfig"
    +
    +config VMI
    + bool "VMI Guest support"
    + select PARAVIRT
    + depends on !(X86_VISWS || X86_VOYAGER)
    + help
    + VMI provides a paravirtualized interface to the VMware ESX server
    + (it could be used by other hypervisors in theory too, but is not
    + at the moment), by linking the kernel to a GPL-ed ROM module
    + provided by the hypervisor.
    +
    +source "arch/x86/lguest/Kconfig"
    +
    +endif
    +
    +config ACPI_SRAT
    + bool
    + default y
    + depends on X86_32 && ACPI && NUMA && (X86_SUMMIT || X86_GENERICARCH)
    + select ACPI_NUMA
    +
    +config HAVE_ARCH_PARSE_SRAT
    + bool
    + default y
    + depends on ACPI_SRAT
    +
    +config X86_SUMMIT_NUMA
    + bool
    + default y
    + depends on X86_32 && NUMA && (X86_SUMMIT || X86_GENERICARCH)
    +
    +config X86_CYCLONE_TIMER
    + bool
    + default y
    + depends on X86_32 && X86_SUMMIT || X86_GENERICARCH
    +
    +config ES7000_CLUSTERED_APIC
    + bool
    + default y
    + depends on SMP && X86_ES7000 && MPENTIUMIII
    +
    +source "arch/x86/Kconfig.cpu"
    +
    +config HPET_TIMER
    + bool
    + prompt "HPET Timer Support" if X86_32
    + default X86_64
    + help
    + Use the IA-PC HPET (High Precision Event Timer) to manage
    + time in preference to the PIT and RTC, if a HPET is
    + present.
    + HPET is the next generation timer replacing legacy 8254s.
    + The HPET provides a stable time base on SMP
    + systems, unlike the TSC, but it is more expensive to access,
    + as it is off-chip. You can find the HPET spec at
    + <http://www.intel.com/hardwaredesign/hpetspec.htm>.
    +
    + You can safely choose Y here. However, HPET will only be
    + activated if the platform and the BIOS support this feature.
    + Otherwise the 8254 will be used for timing services.
    +
    + Choose N to continue using the legacy 8254 timer.
    +
    +config HPET_EMULATE_RTC
    + bool
    + depends on HPET_TIMER && RTC=y
    + default y
    +
    +# Mark as embedded because too many people got it wrong.
    +# The code disables itself when not needed.
    +config GART_IOMMU
    + bool "GART IOMMU support" if EMBEDDED
    + default y
    + select SWIOTLB
    + select AGP
    + depends on X86_64 && PCI
    + help
    + Support for full DMA access of devices with 32bit memory access only
    + on systems with more than 3GB. This is usually needed for USB,
    + sound, many IDE/SATA chipsets and some other devices.
    + Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
    + based hardware IOMMU and a software bounce buffer based IOMMU used
    + on Intel systems and as fallback.
    + The code is only active when needed (enough memory and limited
    + device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
    + too.
    +
    +config CALGARY_IOMMU
    + bool "IBM Calgary IOMMU support"
    + select SWIOTLB
    + depends on X86_64 && PCI && EXPERIMENTAL
    + help
    + Support for hardware IOMMUs in IBM's xSeries x366 and x460
    + systems. Needed to run systems with more than 3GB of memory
    + properly with 32-bit PCI devices that do not support DAC
    + (Double Address Cycle). Calgary also supports bus level
    + isolation, where all DMAs pass through the IOMMU. This
    + prevents them from going anywhere except their intended
    + destination. This catches hard-to-find kernel bugs and
    + mis-behaving drivers and devices that do not use the DMA-API
    + properly to set up their DMA buffers. The IOMMU can be
    + turned off at boot time with the iommu=off parameter.
    + Normally the kernel will make the right choice by itself.
    + If unsure, say Y.
    +
    +config CALGARY_IOMMU_ENABLED_BY_DEFAULT
    + bool "Should Calgary be enabled by default?"
    + default y
    + depends on CALGARY_IOMMU
    + help
    + Should Calgary be enabled by default? if you choose 'y', Calgary
    + will be used (if it exists). If you choose 'n', Calgary will not be
    + used even if it exists. If you choose 'n' and would like to use
    + Calgary anyway, pass 'iommu=calgary' on the kernel command line.
    + If unsure, say Y.
    +
    +# need this always selected by IOMMU for the VIA workaround
    +config SWIOTLB
    + bool
    + help
    + Support for software bounce buffers used on x86-64 systems
    + which don't have a hardware IOMMU (e.g. the current generation
    + of Intel's x86-64 CPUs). Using this PCI devices which can only
    + access 32-bits of memory can be used on systems with more than
    + 3 GB of memory. If unsure, say Y.
    +
    +
    +config NR_CPUS
    + int "Maximum number of CPUs (2-255)"
    + range 2 255
    + depends on SMP
    + default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
    + default "8"
    + help
    + This allows you to specify the maximum number of CPUs which this
    + kernel will support. The maximum supported value is 255 and the
    + minimum value which makes sense is 2.
    +
    + This is purely to save memory - each supported CPU adds
    + approximately eight kilobytes to the kernel image.
    +
    +config SCHED_SMT
    + bool "SMT (Hyperthreading) scheduler support"
    + depends on (X86_64 && SMP) || (X86_32 && X86_HT)
    + help
    + SMT scheduler support improves the CPU scheduler's decision making
    + when dealing with Intel Pentium 4 chips with HyperThreading at a
    + cost of slightly increased overhead in some places. If unsure say
    + N here.
    +
    +config SCHED_MC
    + bool "Multi-core scheduler support"
    + depends on (X86_64 && SMP) || (X86_32 && X86_HT)
    + default y
    + help
    + Multi-core scheduler support improves the CPU scheduler's decision
    + making when dealing with multi-core CPU chips at a cost of slightly
    + increased overhead in some places. If unsure say N here.
    +
    +source "kernel/Kconfig.preempt"
    +
    +config X86_UP_APIC
    + bool "Local APIC support on uniprocessors"
    + depends on X86_32 && !SMP && !(X86_VISWS || X86_VOYAGER || X86_GENERICARCH)
    + help
    + A local APIC (Advanced Programmable Interrupt Controller) is an
    + integrated interrupt controller in the CPU. If you have a single-CPU
    + system which has a processor with a local APIC, you can say Y here to
    + enable and use it. If you say Y here even though your machine doesn't
    + have a local APIC, then the kernel will still run with no slowdown at
    + all. The local APIC supports CPU-generated self-interrupts (timer,
    + performance counters), and the NMI watchdog which detects hard
    + lockups.
    +
    +config X86_UP_IOAPIC
    + bool "IO-APIC support on uniprocessors"
    + depends on X86_UP_APIC
    + help
    + An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an
    + SMP-capable replacement for PC-style interrupt controllers. Most
    + SMP systems and many recent uniprocessor systems have one.
    +
    + If you have a single-CPU system with an IO-APIC, you can say Y here
    + to use it. If you say Y here even though your machine doesn't have
    + an IO-APIC, then the kernel will still run with no slowdown at all.
    +
    +config X86_LOCAL_APIC
    + bool
    + depends on X86_64 || (X86_32 && (X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER) || X86_GENERICARCH))
    + default y
    +
    +config X86_IO_APIC
    + bool
    + depends on X86_64 || (X86_32 && (X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER)) || X86_GENERICARCH))
    + default y
    +
    +config X86_VISWS_APIC
    + bool
    + depends on X86_32 && X86_VISWS
    + default y
    +
    +config X86_MCE
    + bool "Machine Check Exception"
    + depends on !X86_VOYAGER
    + ---help---
    + Machine Check Exception support allows the processor to notify the
    + kernel if it detects a problem (e.g. overheating, component failure).
    + The action the kernel takes depends on the severity of the problem,
    + ranging from a warning message on the console, to halting the machine.
    + Your processor must be a Pentium or newer to support this - check the
    + flags in /proc/cpuinfo for mce. Note that some older Pentium systems
    + have a design flaw which leads to false MCE events - hence MCE is
    + disabled on all P5 processors, unless explicitly enabled with "mce"
    + as a boot argument. Similarly, if MCE is built in and creates a
    + problem on some new non-standard machine, you can boot with "nomce"
    + to disable it. MCE support simply ignores non-MCE processors like
    + the 386 and 486, so nearly everyone can say Y here.
    +
    +config X86_MCE_INTEL
    + bool "Intel MCE features"
    + depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    + default y
    + help
    + Additional support for intel specific MCE features such as
    + the thermal monitor.
    +
    +config X86_MCE_AMD
    + bool "AMD MCE features"
    + depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    + default y
    + help
    + Additional support for AMD specific MCE features such as
    + the DRAM Error Threshold.
    +
    +config X86_MCE_NONFATAL
    + tristate "Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4"
    + depends on X86_32 && X86_MCE
    + help
    + Enabling this feature starts a timer that triggers every 5 seconds which
    + will look at the machine check registers to see if anything happened.
    + Non-fatal problems automatically get corrected (but still logged).
    + Disable this if you don't want to see these messages.
    + Seeing the messages this option prints out may be indicative of dying
    + or out-of-spec (ie, overclocked) hardware.
    + This option only does something on certain CPUs.
    + (AMD Athlon/Duron and Intel Pentium 4)
    +
    +config X86_MCE_P4THERMAL
    + bool "check for P4 thermal throttling interrupt."
    + depends on X86_32 && X86_MCE && (X86_UP_APIC || SMP) && !X86_VISWS
    + help
    + Enabling this feature will cause a message to be printed when the P4
    + enters thermal throttling.
    +
    +config VM86
    + bool "Enable VM86 support" if EMBEDDED
    + default y
    + depends on X86_32
    + help
    + This option is required by programs like DOSEMU to run 16-bit legacy
    + code on X86 processors. It also may be needed by software like
    + XFree86 to initialize some video cards via BIOS. Disabling this
    + option saves about 6k.
    +
    +config TOSHIBA
    + tristate "Toshiba Laptop support"
    + depends on X86_32
    + ---help---
    + This adds a driver to safely access the System Management Mode of
    + the CPU on Toshiba portables with a genuine Toshiba BIOS. It does
    + not work on models with a Phoenix BIOS. The System Management Mode
    + is used to set the BIOS and power saving options on Toshiba portables.
    +
    + For information on utilities to make use of this driver see the
    + Toshiba Linux utilities web site at:
    + <http://www.buzzard.org.uk/toshiba/>.
    +
    + Say Y if you intend to run this kernel on a Toshiba portable.
    + Say N otherwise.
    +
    +config I8K
    + tristate "Dell laptop support"
    + depends on X86_32
    + ---help---
    + This adds a driver to safely access the System Management Mode
    + of the CPU on the Dell Inspiron 8000. The System Management Mode
    + is used to read cpu temperature and cooling fan status and to
    + control the fans on the I8K portables.
    +
    + This driver has been tested only on the Inspiron 8000 but it may
    + also work with other Dell laptops. You can force loading on other
    + models by passing the parameter `force=1' to the module. Use at
    + your own risk.
    +
    + For information on utilities to make use of this driver see the
    + I8K Linux utilities web site at:
    + <http://people.debian.org/~dz/i8k/>
    +
    + Say Y if you intend to run this kernel on a Dell Inspiron 8000.
    + Say N otherwise.
    +
    +config X86_REBOOTFIXUPS
    + bool "Enable X86 board specific fixups for reboot"
    + depends on X86_32 && X86
    + default n
    + ---help---
    + This enables chipset and/or board specific fixups to be done
    + in order to get reboot to work correctly. This is only needed on
    + some combinations of hardware and BIOS. The symptom, for which
    + this config is intended, is when reboot ends with a stalled/hung
    + system.
    +
    + Currently, the only fixup is for the Geode machines using
    + CS5530A and CS5536 chipsets.
    +
    + Say Y if you want to enable the fixup. Currently, it's safe to
    + enable this option even if you don't need it.
    + Say N otherwise.
    +
    +config MICROCODE
    + tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
    + select FW_LOADER
    + ---help---
    + If you say Y here, you will be able to update the microcode on
    + Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
    + Pentium III, Pentium 4, Xeon etc. You will obviously need the
    + actual microcode binary data itself which is not shipped with the
    + Linux kernel.
    +
    + For latest news and information on obtaining all the required
    + ingredients for this driver, check:
    + <http://www.urbanmyth.org/microcode/>.
    +
    + To compile this driver as a module, choose M here: the
    + module will be called microcode.
    +
    +config MICROCODE_OLD_INTERFACE
    + bool
    + depends on MICROCODE
    + default y
    +
    +config X86_MSR
    + tristate "/dev/cpu/*/msr - Model-specific register support"
    + help
    + This device gives privileged processes access to the x86
    + Model-Specific Registers (MSRs). It is a character device with
    + major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
    + MSR accesses are directed to a specific CPU on multi-processor
    + systems.
    +
    +config X86_CPUID
    + tristate "/dev/cpu/*/cpuid - CPU information support"
    + help
    + This device gives processes access to the x86 CPUID instruction to
    + be executed on a specific processor. It is a character device
    + with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
    + /dev/cpu/31/cpuid.
    +
    +choice
    + prompt "High Memory Support"
    + default HIGHMEM4G if !X86_NUMAQ
    + default HIGHMEM64G if X86_NUMAQ
    + depends on X86_32
    +
    +config NOHIGHMEM
    + bool "off"
    + depends on !X86_NUMAQ
    + ---help---
    + Linux can use up to 64 Gigabytes of physical memory on x86 systems.
    + However, the address space of 32-bit x86 processors is only 4
    + Gigabytes large. That means that, if you have a large amount of
    + physical memory, not all of it can be "permanently mapped" by the
    + kernel. The physical memory that's not permanently mapped is called
    + "high memory".
    +
    + If you are compiling a kernel which will never run on a machine with
    + more than 1 Gigabyte total physical RAM, answer "off" here (default
    + choice and suitable for most users). This will result in a "3GB/1GB"
    + split: 3GB are mapped so that each process sees a 3GB virtual memory
    + space and the remaining part of the 4GB virtual memory space is used
    + by the kernel to permanently map as much physical memory as
    + possible.
    +
    + If the machine has between 1 and 4 Gigabytes physical RAM, then
    + answer "4GB" here.
    +
    + If more than 4 Gigabytes is used then answer "64GB" here. This
    + selection turns Intel PAE (Physical Address Extension) mode on.
    + PAE implements 3-level paging on IA32 processors. PAE is fully
    + supported by Linux, PAE mode is implemented on all recent Intel
    + processors (Pentium Pro and better). NOTE: If you say "64GB" here,
    + then the kernel will not boot on CPUs that don't support PAE!
    +
    + The actual amount of total physical memory will either be
    + auto detected or can be forced by using a kernel command line option
    + such as "mem=256M". (Try "man bootparam" or see the documentation of
    + your boot loader (lilo or loadlin) about how to pass options to the
    + kernel at boot time.)
    +
    + If unsure, say "off".
    +
    +config HIGHMEM4G
    + bool "4GB"
    + depends on !X86_NUMAQ
    + help
    + Select this if you have a 32-bit processor and between 1 and 4
    + gigabytes of physical RAM.
    +
    +config HIGHMEM64G
    + bool "64GB"
    + depends on !M386 && !M486
    + select X86_PAE
    + help
    + Select this if you have a 32-bit processor and more than 4
    + gigabytes of physical RAM.
    +
    +endchoice
    +
    +choice
    + depends on EXPERIMENTAL
    + prompt "Memory split" if EMBEDDED
    + default VMSPLIT_3G
    + depends on X86_32
    + help
    + Select the desired split between kernel and user memory.
    +
    + If the address range available to the kernel is less than the
    + physical memory installed, the remaining memory will be available
    + as "high memory". Accessing high memory is a little more costly
    + than low memory, as it needs to be mapped into the kernel first.
    + Note that increasing the kernel address space limits the range
    + available to user programs, making the address space there
    + tighter. Selecting anything other than the default 3G/1G split
    + will also likely make your kernel incompatible with binary-only
    + kernel modules.
    +
    + If you are not absolutely sure what you are doing, leave this
    + option alone!
    +
    + config VMSPLIT_3G
    + bool "3G/1G user/kernel split"
    + config VMSPLIT_3G_OPT
    + depends on !X86_PAE
    + bool "3G/1G user/kernel split (for full 1G low memory)"
    + config VMSPLIT_2G
    + bool "2G/2G user/kernel split"
    + config VMSPLIT_2G_OPT
    + depends on !X86_PAE
    + bool "2G/2G user/kernel split (for full 2G low memory)"
    + config VMSPLIT_1G
    + bool "1G/3G user/kernel split"
    +endchoice
    +
    +config PAGE_OFFSET
    + hex
    + default 0xB0000000 if VMSPLIT_3G_OPT
    + default 0x80000000 if VMSPLIT_2G
    + default 0x78000000 if VMSPLIT_2G_OPT
    + default 0x40000000 if VMSPLIT_1G
    + default 0xC0000000
    + depends on X86_32
    +
    +config HIGHMEM
    + bool
    + depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
    + default y
    +
    +config X86_PAE
    + bool "PAE (Physical Address Extension) Support"
    + default n
    + depends on X86_32 && !HIGHMEM4G
    + select RESOURCES_64BIT
    + help
    + PAE is required for NX support, and furthermore enables
    + larger swapspace support for non-overcommit purposes. It
    + has the cost of more pagetable lookup overhead, and also
    + consumes more pagetable space per process.
    +
    +# Common NUMA Features
    +config NUMA
    + bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
    + depends on SMP
    + depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
    + default n if X86_PC
    + default y if (X86_NUMAQ || X86_SUMMIT)
    + help
    + Enable NUMA (Non Uniform Memory Access) support.
    + The kernel will try to allocate memory used by a CPU on the
    + local memory controller of the CPU and add some more
    + NUMA awareness to the kernel.
    +
    + For i386 this is currently highly experimental and should be only
    + used for kernel development. It might also cause boot failures.
    + For x86_64 this is recommended on all multiprocessor Opteron systems.
    + If the system is EM64T, you should say N unless your system is
    + EM64T NUMA.
    +
    +comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
    + depends on X86_32 && X86_SUMMIT && (!HIGHMEM64G || !ACPI)
    +
    +config K8_NUMA
    + bool "Old style AMD Opteron NUMA detection"
    + depends on X86_64 && NUMA && PCI
    + default y
    + help
    + Enable K8 NUMA node topology detection. You should say Y here if
    + you have a multi processor AMD K8 system. This uses an old
    + method to read the NUMA configuration directly from the builtin
    + Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
    + instead, which also takes priority if both are compiled in.
    +
    +config X86_64_ACPI_NUMA
    + bool "ACPI NUMA detection"
    + depends on X86_64 && NUMA && ACPI && PCI
    + select ACPI_NUMA
    + default y
    + help
    + Enable ACPI SRAT based node topology detection.
    +
    +config NUMA_EMU
    + bool "NUMA emulation"
    + depends on X86_64 && NUMA
    + help
    + Enable NUMA emulation. A flat machine will be split
    + into virtual nodes when booted with "numa=fake=N", where N is the
    + number of nodes. This is only useful for debugging.
    +
    +config NODES_SHIFT
    + int
    + default "6" if X86_64
    + default "4" if X86_NUMAQ
    + default "3"
    + depends on NEED_MULTIPLE_NODES
    +
    +config HAVE_ARCH_BOOTMEM_NODE
    + bool
    + depends on X86_32 && NUMA
    + default y
    +
    +config ARCH_HAVE_MEMORY_PRESENT
    + bool
    + depends on X86_32 && DISCONTIGMEM
    + default y
    +
    +config NEED_NODE_MEMMAP_SIZE
    + bool
    + depends on X86_32 && (DISCONTIGMEM || SPARSEMEM)
    + default y
    +
    +config HAVE_ARCH_ALLOC_REMAP
    + bool
    + depends on X86_32 && NUMA
    + default y
    +
    +config ARCH_FLATMEM_ENABLE
    + def_bool y
    + depends on (X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC) || (X86_64 && !NUMA)
    +
    +config ARCH_DISCONTIGMEM_ENABLE
    + def_bool y
    + depends on NUMA
    +
    +config ARCH_DISCONTIGMEM_DEFAULT
    + def_bool y
    + depends on NUMA
    +
    +config ARCH_SPARSEMEM_ENABLE
    + def_bool y
    + depends on NUMA || (EXPERIMENTAL && (X86_PC || X86_64))
    + select SPARSEMEM_STATIC if X86_32
    + select SPARSEMEM_VMEMMAP_ENABLE if X86_64
    +
    +config ARCH_SELECT_MEMORY_MODEL
    + def_bool y
    + depends on X86_32 && ARCH_SPARSEMEM_ENABLE
    +
    +config ARCH_MEMORY_PROBE
    + def_bool X86_64
    + depends on MEMORY_HOTPLUG
    +
    +source "mm/Kconfig"
    +
    +config HIGHPTE
    + bool "Allocate 3rd-level pagetables from highmem"
    + depends on X86_32 && (HIGHMEM4G || HIGHMEM64G)
    + help
    + The VM uses one page table entry for each page of physical memory.
    + For systems with a lot of RAM, this can be wasteful of precious
    + low memory. Setting this option will put user-space page table
    + entries in high memory.
    +
    +config MATH_EMULATION
    + bool
    + prompt "Math emulation" if X86_32
    + ---help---
    + Linux can emulate a math coprocessor (used for floating point
    + operations) if you don't have one. 486DX and Pentium processors have
    + a math coprocessor built in, 486SX and 386 do not, unless you added
    + a 487DX or 387, respectively. (The messages during boot time can
    + give you some hints here ["man dmesg"].) Everyone needs either a
    + coprocessor or this emulation.
    +
    + If you don't have a math coprocessor, you need to say Y here; if you
    + say Y here even though you have a coprocessor, the coprocessor will
    + be used nevertheless. (This behavior can be changed with the kernel
    + command line option "no387", which comes handy if your coprocessor
    + is broken. Try "man bootparam" or see the documentation of your boot
    + loader (lilo or loadlin) about how to pass options to the kernel at
    + boot time.) This means that it is a good idea to say Y here if you
    + intend to use this kernel on different machines.
    +
    + More information about the internals of the Linux math coprocessor
    + emulation can be found in <file:arch/x86/math-emu/README>.
    +
    + If you are not sure, say Y; apart from resulting in a 66 KB bigger
    + kernel, it won't hurt.
    +
    +config MTRR
    + bool "MTRR (Memory Type Range Register) support"
    + ---help---
    + On Intel P6 family processors (Pentium Pro, Pentium II and later)
    + the Memory Type Range Registers (MTRRs) may be used to control
    + processor access to memory ranges. This is most useful if you have
    + a video (VGA) card on a PCI or AGP bus. Enabling write-combining
    + allows bus write transfers to be combined into a larger transfer
    + before bursting over the PCI/AGP bus. This can increase performance
    + of image write operations 2.5 times or more. Saying Y here creates a
    + /proc/mtrr file which may be used to manipulate your processor's
    + MTRRs. Typically the X server should use this.
    +
    + This code has a reasonably generic interface so that similar
    + control registers on other processors can be easily supported
    + as well:
    +
    + The Cyrix 6x86, 6x86MX and M II processors have Address Range
    + Registers (ARRs) which provide a similar functionality to MTRRs. For
    + these, the ARRs are used to emulate the MTRRs.
    + The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
    + MTRRs. The Centaur C6 (WinChip) has 8 MCRs, allowing
    + write-combining. All of these processors are supported by this code
    + and it makes sense to say Y here if you have one of them.
    +
    + Saying Y here also fixes a problem with buggy SMP BIOSes which only
    + set the MTRRs for the boot CPU and not for the secondary CPUs. This
    + can lead to all sorts of problems, so it's good to say Y here.
    +
    + You can safely say Y even if your machine doesn't have MTRRs, you'll
    + just add about 9 KB to your kernel.
    +
    + See <file:Documentation/mtrr.txt> for more information.
    +
    +config EFI
    + bool "Boot from EFI support"
    + depends on X86_32 && ACPI
    + default n
    + ---help---
    + This enables the kernel to boot on EFI platforms using
    + system configuration information passed to it from the firmware.
    + This also enables the kernel to use any EFI runtime services that are
    + available (such as the EFI variable services).
    +
    + This option is only useful on systems that have EFI firmware
    + and will result in a kernel image that is ~8k larger. In addition,
    + you must use the latest ELILO loader available at
    + <http://elilo.sourceforge.net> in order to take advantage of
    + kernel initialization using EFI information (neither GRUB nor LILO know
    + anything about EFI). However, even with this option, the resultant
    + kernel should continue to boot on existing non-EFI platforms.
    +
    +config IRQBALANCE
    + bool "Enable kernel irq balancing"
    + depends on X86_32 && SMP && X86_IO_APIC
    + default y
    + help
    + The default yes will allow the kernel to do irq load balancing.
    + Saying no will keep the kernel from doing irq load balancing.
    +
    +# turning this on wastes a bunch of space.
    +# Summit needs it only when NUMA is on
    +config BOOT_IOREMAP
    + bool
    + depends on X86_32 && (((X86_SUMMIT || X86_GENERICARCH) && NUMA) || (X86 && EFI))
    + default y
    +
    +config SECCOMP
    + bool "Enable seccomp to safely compute untrusted bytecode"
    + depends on PROC_FS
    + default y
    + help
    + This kernel feature is useful for number crunching applications
    + that may need to compute untrusted bytecode during their
    + execution. By using pipes or other transports made available to
    + the process as file descriptors supporting the read/write
    + syscalls, it's possible to isolate those applications in
    + their own address space using seccomp. Once seccomp is
    + enabled via /proc/<pid>/seccomp, it cannot be disabled
    + and the task is only allowed to execute a few safe syscalls
    + defined by each seccomp mode.
    +
    + If unsure, say Y. Only embedded should say N here.
    +
    +config CC_STACKPROTECTOR
    + bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
    + depends on X86_64 && EXPERIMENTAL
    + help
    + This option turns on the -fstack-protector GCC feature. This
    + feature puts, at the beginning of critical functions, a canary
    + value on the stack just before the return address, and validates
    + the value just before actually returning. Stack based buffer
    + overflows (that need to overwrite this return address) now also
    + overwrite the canary, which gets detected and the attack is then
    + neutralized via a kernel panic.
    +
    + This feature requires gcc version 4.2 or above, or a distribution
    + gcc with the feature backported. Older versions are automatically
    + detected and for those versions, this configuration option is ignored.
    +
    +config CC_STACKPROTECTOR_ALL
    + bool "Use stack-protector for all functions"
    + depends on CC_STACKPROTECTOR
    + help
    + Normally, GCC only inserts the canary value protection for
    + functions that use large-ish on-stack buffers. By enabling
    + this option, GCC will be asked to do this for ALL functions.
    +
    +source kernel/Kconfig.hz
    +
    +config KEXEC
    + bool "kexec system call"
    + help
    + kexec is a system call that implements the ability to shutdown your
    + current kernel, and to start another kernel. It is like a reboot
    + but it is independent of the system firmware. And like a reboot
    + you can start any kernel with it, not just Linux.
    +
    + The name comes from the similarity to the exec system call.
    +
    + It is an ongoing process to be certain the hardware in a machine
    + is properly shutdown, so do not be surprised if this code does not
    + initially work for you. It may help to enable device hotplugging
    + support. As of this writing the exact hardware interface is
    + strongly in flux, so no good recommendation can be made.
    +
    +config CRASH_DUMP
    + bool "kernel crash dumps (EXPERIMENTAL)"
    + depends on EXPERIMENTAL
    + depends on X86_64 || (X86_32 && HIGHMEM)
    + help
    + Generate crash dump after being started by kexec.
    + This should be normally only set in special crash dump kernels
    + which are loaded in the main kernel with kexec-tools into
    + a specially reserved region and then later executed after
    + a crash by kdump/kexec. The crash dump kernel must be compiled
    + to a memory address not used by the main kernel or BIOS using
    + PHYSICAL_START, or it must be built as a relocatable image
    + (CONFIG_RELOCATABLE=y).
    + For more details see Documentation/kdump/kdump.txt
    +
    +config PHYSICAL_START
    + hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
    + default "0x1000000" if X86_NUMAQ
    + default "0x200000" if X86_64
    + default "0x100000"
    + help
    + This gives the physical address where the kernel is loaded.
    +
    + If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
    + bzImage will decompress itself to above physical address and
    + run from there. Otherwise, bzImage will run from the address where
    + it has been loaded by the boot loader and will ignore above physical
    + address.
    +
    + In normal kdump cases one does not have to set/change this option
    + as now bzImage can be compiled as a completely relocatable image
    + (CONFIG_RELOCATABLE=y) and be used to load and run from a different
    + address. This option is mainly useful for the folks who don't want
    + to use a bzImage for capturing the crash dump and want to use a
    + vmlinux instead. vmlinux is not relocatable hence a kernel needs
    + to be specifically compiled to run from a specific memory area
    + (normally a reserved region) and this option comes handy.
    +
    + So if you are using bzImage for capturing the crash dump, leave
    + the value here unchanged to 0x100000 and set CONFIG_RELOCATABLE=y.
    + Otherwise if you plan to use vmlinux for capturing the crash dump
    + change this value to start of the reserved region (Typically 16MB
    + 0x1000000). In other words, it can be set based on the "X" value as
    + specified in the "crashkernel=YM@XM" command line boot parameter
    + passed to the panic-ed kernel. Typically this parameter is set as
    + crashkernel=64M@16M. Please take a look at
    + Documentation/kdump/kdump.txt for more details about crash dumps.
    +
    + Usage of bzImage for capturing the crash dump is recommended as
    + one does not have to build two kernels. Same kernel can be used
    + as production kernel and capture kernel. Above option should have
    + gone away after relocatable bzImage support is introduced. But it
    + is present because there are users out there who continue to use
    + vmlinux for dump capture. This option should go away down the
    + line.
    +
    + Don't change this unless you know what you are doing.
    +
    +config RELOCATABLE
    + bool "Build a relocatable kernel (EXPERIMENTAL)"
    + depends on EXPERIMENTAL
    + help
    + This builds a kernel image that retains relocation information
    + so it can be loaded someplace besides the default 1MB.
    + The relocations tend to make the kernel binary about 10% larger,
    + but are discarded at runtime.
    +
    + One use is for the kexec on panic case where the recovery kernel
    + must live at a different physical address than the primary
    + kernel.
    +
    + Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
    + it has been loaded at and the compile time physical address
    + (CONFIG_PHYSICAL_START) is ignored.
    +
    +config PHYSICAL_ALIGN
    + hex
    + prompt "Alignment value to which kernel should be aligned" if X86_32
    + default "0x100000" if X86_32
    + default "0x200000" if X86_64
    + range 0x2000 0x400000
    + help
    + This value puts the alignment restrictions on physical address
    + where kernel is loaded and run from. Kernel is compiled for an
    + address which meets above alignment restriction.
    +
    + If bootloader loads the kernel at a non-aligned address and
    + CONFIG_RELOCATABLE is set, kernel will move itself to nearest
    + address aligned to above value and run from there.
    +
    + If bootloader loads the kernel at a non-aligned address and
    + CONFIG_RELOCATABLE is not set, kernel will ignore the run time
    + load address and decompress itself to the address it has been
    + compiled for and run from there. The address for which kernel is
    + compiled already meets above alignment restrictions. Hence the
    + end result is that kernel runs from a physical address meeting
    + above alignment restrictions.
    +
    + Don't change this unless you know what you are doing.
    +
    +config HOTPLUG_CPU
    + bool "Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL)"
    + depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
    + ---help---
    + Say Y here to experiment with turning CPUs off and on, and to
    + enable suspend on SMP systems. CPUs can be controlled through
    + /sys/devices/system/cpu.
    + Say N if you want to disable CPU hotplug and don't need to
    + suspend.
    +
    +config COMPAT_VDSO
    + bool "Compat VDSO support"
    + default y
    + depends on X86_32
    + help
    + Map the VDSO to the predictable old-style address too.
    + ---help---
    + Say N here if you are running a sufficiently recent glibc
    + version (2.3.3 or later), to remove the high-mapped
    + VDSO mapping and to exclusively use the randomized VDSO.
    +
    + If unsure, say Y.
    +
    +endmenu
    +
    +config ARCH_ENABLE_MEMORY_HOTPLUG
    + def_bool y
    + depends on X86_64 || (X86_32 && HIGHMEM)
    +
    +config MEMORY_HOTPLUG_RESERVE
    + def_bool X86_64
    + depends on (MEMORY_HOTPLUG && DISCONTIGMEM)
    +
    +config HAVE_ARCH_EARLY_PFN_TO_NID
    + def_bool X86_64
    + depends on NUMA
    +
    +config OUT_OF_LINE_PFN_TO_PAGE
    + def_bool X86_64
    + depends on DISCONTIGMEM

    menu "Power management options"
    depends on !X86_VOYAGER
    diff --git a/arch/x86/Kconfig.i386 b/arch/x86/Kconfig.i386
    index b8b462a..7b8dc26 100644
    --- a/arch/x86/Kconfig.i386
    +++ b/arch/x86/Kconfig.i386
    @@ -14,1058 +14,5 @@ config X86_32
    486, 586, Pentiums, and various instruction-set-compatible chips by
    AMD, Cyrix, and others.

    -source "init/Kconfig"
    -
    -menu "Processor type and features"
    -
    -source "kernel/time/Kconfig"
    -
    -config SMP
    - bool "Symmetric multi-processing support"
    - ---help---
    - This enables support for systems with more than one CPU. If you have
    - a system with only one CPU, like most personal computers, say N. If
    - you have a system with more than one CPU, say Y.
    -
    - If you say N here, the kernel will run on single and multiprocessor
    - machines, but will use only one CPU of a multiprocessor machine. If
    - you say Y here, the kernel will run on many, but not all,
    - singleprocessor machines. On a singleprocessor machine, the kernel
    - will run faster if you say N here.
    -
    - Note that if you say Y here and choose architecture "586" or
    - "Pentium" under "Processor family", the kernel will not work on 486
    - architectures. Similarly, multiprocessor kernels for the "PPro"
    - architecture may not work on all Pentium based boards.
    -
    - People using multiprocessor machines who say Y here should also say
    - Y to "Enhanced Real Time Clock Support", below. The "Advanced Power
    - Management" code will be disabled if you say Y here.
    -
    - See also the <file:Documentation/smp.txt>,
    - <file:Documentation/i386/IO-APIC.txt>,
    - <file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO available at
    - <http://www.tldp.org/docs.html#howto>.
    -
    - If you don't know what to do here, say N.
    -
    -choice
    - prompt "Subarchitecture Type"
    - default X86_PC
    -
    -config X86_PC
    - bool "PC-compatible"
    - help
    - Choose this option if your computer is a standard PC or compatible.
    -
    -config X86_ELAN
    - bool "AMD Elan"
    - depends on X86_32
    - help
    - Select this for an AMD Elan processor.
    -
    - Do not use this option for K6/Athlon/Opteron processors!
    -
    - If unsure, choose "PC-compatible" instead.
    -
    -config X86_VOYAGER
    - bool "Voyager (NCR)"
    - depends on X86_32
    - select SMP if !BROKEN
    - help
    - Voyager is an MCA-based 32-way capable SMP architecture proprietary
    - to NCR Corp. Machine classes 345x/35xx/4100/51xx are Voyager-based.
    -
    - *** WARNING ***
    -
    - If you do not specifically know you have a Voyager based machine,
    - say N here, otherwise the kernel you build will not be bootable.
    -
    -config X86_NUMAQ
    - bool "NUMAQ (IBM/Sequent)"
    - select SMP
    - select NUMA
    - depends on X86_32
    - help
    - This option is used for getting Linux to run on a (IBM/Sequent) NUMA
    - multiquad box. This changes the way that processors are bootstrapped,
    - and uses Clustered Logical APIC addressing mode instead of Flat Logical.
    - You will need a new lynxer.elf file to flash your firmware with - send
    - email to <Martin.Bligh@us.ibm.com>.
    -
    -config X86_SUMMIT
    - bool "Summit/EXA (IBM x440)"
    - depends on X86_32 && SMP
    - help
    - This option is needed for IBM systems that use the Summit/EXA chipset.
    - In particular, it is needed for the x440.
    -
    - If you don't have one of these computers, you should say N here.
    - If you want to build a NUMA kernel, you must select ACPI.
    -
    -config X86_BIGSMP
    - bool "Support for other sub-arch SMP systems with more than 8 CPUs"
    - depends on X86_32 && SMP
    - help
    - This option is needed for the systems that have more than 8 CPUs
    - and if the system is not of any sub-arch type above.
    -
    - If you don't have such a system, you should say N here.
    -
    -config X86_VISWS
    - bool "SGI 320/540 (Visual Workstation)"
    - depends on X86_32
    - help
    - The SGI Visual Workstation series is an IA32-based workstation
    - based on SGI systems chips with some legacy PC hardware attached.
    -
    - Say Y here to create a kernel to run on the SGI 320 or 540.
    -
    - A kernel compiled for the Visual Workstation will not run on PCs
    - and vice versa. See <file:Documentation/sgi-visws.txt> for details.
    -
    -config X86_GENERICARCH
    - bool "Generic architecture (Summit, bigsmp, ES7000, default)"
    - depends on X86_32
    - help
    - This option compiles in the Summit, bigsmp, ES7000, default subarchitectures.
    - It is intended for a generic binary kernel.
    - If you want a NUMA kernel, select ACPI. We need SRAT for NUMA.
    -
    -config X86_ES7000
    - bool "Support for Unisys ES7000 IA32 series"
    - depends on X86_32 && SMP
    - help
    - Support for Unisys ES7000 systems. Say 'Y' here if this kernel is
    - supposed to run on an IA32-based Unisys ES7000 system.
    - Only choose this option if you have such a system, otherwise you
    - should say N here.
    -
    -config X86_VSMP
    - bool "Support for ScaleMP vSMP"
    - depends on X86_64 && PCI
    - help
    - Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
    - supposed to run on these EM64T-based machines. Only choose this option
    - if you have one of these machines.
    -
    -endchoice
    -
    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    - bool "Single-depth WCHAN output"
    - default y
    - depends on X86_32
    - help
    - Calculate simpler /proc/<PID>/wchan values. If this option
    - is disabled then wchan values will recurse back to the
    - caller function. This provides more accurate wchan values,
    - at the expense of slightly more scheduling overhead.
    -
    - If in doubt, say "Y".
    -
    -config PARAVIRT
    - bool
    - depends on X86_32 && !(X86_VISWS || X86_VOYAGER)
    - help
    - This changes the kernel so it can modify itself when it is run
    - under a hypervisor, potentially improving performance significantly
    - over full virtualization. However, when run without a hypervisor
    - the kernel is theoretically slower and slightly larger.
    -
    -menuconfig PARAVIRT_GUEST
    - bool "Paravirtualized guest support"
    - depends on X86_32
    - help
    - Say Y here to get to see options related to running Linux under
    - various hypervisors. This option alone does not add any kernel code.
    -
    - If you say N, all options in this submenu will be skipped and disabled.
    -
    -if PARAVIRT_GUEST
    -
    -source "arch/x86/xen/Kconfig"
    -
    -config VMI
    - bool "VMI Guest support"
    - select PARAVIRT
    - depends on !(X86_VISWS || X86_VOYAGER)
    - help
    - VMI provides a paravirtualized interface to the VMware ESX server
    - (it could be used by other hypervisors in theory too, but is not
    - at the moment), by linking the kernel to a GPL-ed ROM module
    - provided by the hypervisor.
    -
    -source "arch/x86/lguest/Kconfig"
    -
    -endif
    -
    -config ACPI_SRAT
    - bool
    - default y
    - depends on X86_32 && ACPI && NUMA && (X86_SUMMIT || X86_GENERICARCH)
    - select ACPI_NUMA
    -
    -config HAVE_ARCH_PARSE_SRAT
    - bool
    - default y
    - depends on ACPI_SRAT
    -
    -config X86_SUMMIT_NUMA
    - bool
    - default y
    - depends on X86_32 && NUMA && (X86_SUMMIT || X86_GENERICARCH)
    -
    -config X86_CYCLONE_TIMER
    - bool
    - default y
    - depends on X86_32 && X86_SUMMIT || X86_GENERICARCH
    -
    -config ES7000_CLUSTERED_APIC
    - bool
    - default y
    - depends on SMP && X86_ES7000 && MPENTIUMIII
    -
    -source "arch/x86/Kconfig.cpu"
    -
    -config HPET_TIMER
    - bool
    - prompt "HPET Timer Support" if X86_32
    - default X86_64
    - help
    - Use the IA-PC HPET (High Precision Event Timer) to manage
    - time in preference to the PIT and RTC, if a HPET is
    - present.
    - HPET is the next generation timer replacing legacy 8254s.
    - The HPET provides a stable time base on SMP
    - systems, unlike the TSC, but it is more expensive to access,
    - as it is off-chip. You can find the HPET spec at
    - <http://www.intel.com/hardwaredesign/hpetspec.htm>.
    -
    - You can safely choose Y here. However, HPET will only be
    - activated if the platform and the BIOS support this feature.
    - Otherwise the 8254 will be used for timing services.
    -
    - Choose N to continue using the legacy 8254 timer.
    -
    -config HPET_EMULATE_RTC
    - bool
    - depends on HPET_TIMER && RTC=y
    - default y
    -
    -# Mark as embedded because too many people got it wrong.
    -# The code disables itself when not needed.
    -config GART_IOMMU
    - bool "GART IOMMU support" if EMBEDDED
    - default y
    - select SWIOTLB
    - select AGP
    - depends on X86_64 && PCI
    - help
    - Support for full DMA access of devices with 32bit memory access only
    - on systems with more than 3GB. This is usually needed for USB,
    - sound, many IDE/SATA chipsets and some other devices.
    - Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
    - based hardware IOMMU and a software bounce buffer based IOMMU used
    - on Intel systems and as fallback.
    - The code is only active when needed (enough memory and limited
    - device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
    - too.
    -
    -config CALGARY_IOMMU
    - bool "IBM Calgary IOMMU support"
    - select SWIOTLB
    - depends on X86_64 && PCI && EXPERIMENTAL
    - help
    - Support for hardware IOMMUs in IBM's xSeries x366 and x460
    - systems. Needed to run systems with more than 3GB of memory
    - properly with 32-bit PCI devices that do not support DAC
    - (Double Address Cycle). Calgary also supports bus level
    - isolation, where all DMAs pass through the IOMMU. This
    - prevents them from going anywhere except their intended
    - destination. This catches hard-to-find kernel bugs and
    - mis-behaving drivers and devices that do not use the DMA-API
    - properly to set up their DMA buffers. The IOMMU can be
    - turned off at boot time with the iommu=off parameter.
    - Normally the kernel will make the right choice by itself.
    - If unsure, say Y.
    -
    -config CALGARY_IOMMU_ENABLED_BY_DEFAULT
    - bool "Should Calgary be enabled by default?"
    - default y
    - depends on CALGARY_IOMMU
    - help
    - Should Calgary be enabled by default? if you choose 'y', Calgary
    - will be used (if it exists). If you choose 'n', Calgary will not be
    - used even if it exists. If you choose 'n' and would like to use
    - Calgary anyway, pass 'iommu=calgary' on the kernel command line.
    - If unsure, say Y.
    -
    -# need this always selected by IOMMU for the VIA workaround
    -config SWIOTLB
    - bool
    - help
    - Support for software bounce buffers used on x86-64 systems
    - which don't have a hardware IOMMU (e.g. the current generation
    - of Intel's x86-64 CPUs). Using this PCI devices which can only
    - access 32-bits of memory can be used on systems with more than
    - 3 GB of memory. If unsure, say Y.
    -
    -
    -config NR_CPUS
    - int "Maximum number of CPUs (2-255)"
    - range 2 255
    - depends on SMP
    - default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
    - default "8"
    - help
    - This allows you to specify the maximum number of CPUs which this
    - kernel will support. The maximum supported value is 255 and the
    - minimum value which makes sense is 2.
    -
    - This is purely to save memory - each supported CPU adds
    - approximately eight kilobytes to the kernel image.
    -
    -config SCHED_SMT
    - bool "SMT (Hyperthreading) scheduler support"
    - depends on (X86_64 && SMP) || (X86_32 && X86_HT)
    - help
    - SMT scheduler support improves the CPU scheduler's decision making
    - when dealing with Intel Pentium 4 chips with HyperThreading at a
    - cost of slightly increased overhead in some places. If unsure say
    - N here.
    -
    -config SCHED_MC
    - bool "Multi-core scheduler support"
    - depends on (X86_64 && SMP) || (X86_32 && X86_HT)
    - default y
    - help
    - Multi-core scheduler support improves the CPU scheduler's decision
    - making when dealing with multi-core CPU chips at a cost of slightly
    - increased overhead in some places. If unsure say N here.
    -
    -source "kernel/Kconfig.preempt"
    -
    -config X86_UP_APIC
    - bool "Local APIC support on uniprocessors"
    - depends on X86_32 && !SMP && !(X86_VISWS || X86_VOYAGER || X86_GENERICARCH)
    - help
    - A local APIC (Advanced Programmable Interrupt Controller) is an
    - integrated interrupt controller in the CPU. If you have a single-CPU
    - system which has a processor with a local APIC, you can say Y here to
    - enable and use it. If you say Y here even though your machine doesn't
    - have a local APIC, then the kernel will still run with no slowdown at
    - all. The local APIC supports CPU-generated self-interrupts (timer,
    - performance counters), and the NMI watchdog which detects hard
    - lockups.
    -
    -config X86_UP_IOAPIC
    - bool "IO-APIC support on uniprocessors"
    - depends on X86_UP_APIC
    - help
    - An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an
    - SMP-capable replacement for PC-style interrupt controllers. Most
    - SMP systems and many recent uniprocessor systems have one.
    -
    - If you have a single-CPU system with an IO-APIC, you can say Y here
    - to use it. If you say Y here even though your machine doesn't have
    - an IO-APIC, then the kernel will still run with no slowdown at all.
    -
    -config X86_LOCAL_APIC
    - bool
    - depends on X86_64 || (X86_32 && (X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER) || X86_GENERICARCH))
    - default y
    -
    -config X86_IO_APIC
    - bool
    - depends on X86_64 || (X86_32 && (X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER)) || X86_GENERICARCH))
    - default y
    -
    -config X86_VISWS_APIC
    - bool
    - depends on X86_32 && X86_VISWS
    - default y
    -
    -config X86_MCE
    - bool "Machine Check Exception"
    - depends on !X86_VOYAGER
    - ---help---
    - Machine Check Exception support allows the processor to notify the
    - kernel if it detects a problem (e.g. overheating, component failure).
    - The action the kernel takes depends on the severity of the problem,
    - ranging from a warning message on the console, to halting the machine.
    - Your processor must be a Pentium or newer to support this - check the
    - flags in /proc/cpuinfo for mce. Note that some older Pentium systems
    - have a design flaw which leads to false MCE events - hence MCE is
    - disabled on all P5 processors, unless explicitly enabled with "mce"
    - as a boot argument. Similarly, if MCE is built in and creates a
    - problem on some new non-standard machine, you can boot with "nomce"
    - to disable it. MCE support simply ignores non-MCE processors like
    - the 386 and 486, so nearly everyone can say Y here.
    -
    -config X86_MCE_INTEL
    - bool "Intel MCE features"
    - depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    - default y
    - help
    - Additional support for intel specific MCE features such as
    - the thermal monitor.
    -
    -config X86_MCE_AMD
    - bool "AMD MCE features"
    - depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    - default y
    - help
    - Additional support for AMD specific MCE features such as
    - the DRAM Error Threshold.
    -
    -config X86_MCE_NONFATAL
    - tristate "Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4"
    - depends on X86_32 && X86_MCE
    - help
    - Enabling this feature starts a timer that triggers every 5 seconds which
    - will look at the machine check registers to see if anything happened.
    - Non-fatal problems automatically get corrected (but still logged).
    - Disable this if you don't want to see these messages.
    - Seeing the messages this option prints out may be indicative of dying
    - or out-of-spec (ie, overclocked) hardware.
    - This option only does something on certain CPUs.
    - (AMD Athlon/Duron and Intel Pentium 4)
    -
    -config X86_MCE_P4THERMAL
    - bool "check for P4 thermal throttling interrupt."
    - depends on X86_32 && X86_MCE && (X86_UP_APIC || SMP) && !X86_VISWS
    - help
    - Enabling this feature will cause a message to be printed when the P4
    - enters thermal throttling.
    -
    -config VM86
    - bool "Enable VM86 support" if EMBEDDED
    - default y
    - depends on X86_32
    - help
    - This option is required by programs like DOSEMU to run 16-bit legacy
    - code on X86 processors. It also may be needed by software like
    - XFree86 to initialize some video cards via BIOS. Disabling this
    - option saves about 6k.
    -
    -config TOSHIBA
    - tristate "Toshiba Laptop support"
    - depends on X86_32
    - ---help---
    - This adds a driver to safely access the System Management Mode of
    - the CPU on Toshiba portables with a genuine Toshiba BIOS. It does
    - not work on models with a Phoenix BIOS. The System Management Mode
    - is used to set the BIOS and power saving options on Toshiba portables.
    -
    - For information on utilities to make use of this driver see the
    - Toshiba Linux utilities web site at:
    - <http://www.buzzard.org.uk/toshiba/>.
    -
    - Say Y if you intend to run this kernel on a Toshiba portable.
    - Say N otherwise.
    -
    -config I8K
    - tristate "Dell laptop support"
    - depends on X86_32
    - ---help---
    - This adds a driver to safely access the System Management Mode
    - of the CPU on the Dell Inspiron 8000. The System Management Mode
    - is used to read cpu temperature and cooling fan status and to
    - control the fans on the I8K portables.
    -
    - This driver has been tested only on the Inspiron 8000 but it may
    - also work with other Dell laptops. You can force loading on other
    - models by passing the parameter `force=1' to the module. Use at
    - your own risk.
    -
    - For information on utilities to make use of this driver see the
    - I8K Linux utilities web site at:
    - <http://people.debian.org/~dz/i8k/>
    -
    - Say Y if you intend to run this kernel on a Dell Inspiron 8000.
    - Say N otherwise.
    -
    -config X86_REBOOTFIXUPS
    - bool "Enable X86 board specific fixups for reboot"
    - depends on X86_32 && X86
    - default n
    - ---help---
    - This enables chipset and/or board specific fixups to be done
    - in order to get reboot to work correctly. This is only needed on
    - some combinations of hardware and BIOS. The symptom, for which
    - this config is intended, is when reboot ends with a stalled/hung
    - system.
    -
    - Currently, the only fixup is for the Geode machines using
    - CS5530A and CS5536 chipsets.
    -
    - Say Y if you want to enable the fixup. Currently, it's safe to
    - enable this option even if you don't need it.
    - Say N otherwise.
    -
    -config MICROCODE
    - tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
    - select FW_LOADER
    - ---help---
    - If you say Y here, you will be able to update the microcode on
    - Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
    - Pentium III, Pentium 4, Xeon etc. You will obviously need the
    - actual microcode binary data itself which is not shipped with the
    - Linux kernel.
    -
    - For latest news and information on obtaining all the required
    - ingredients for this driver, check:
    - <http://www.urbanmyth.org/microcode/>.
    -
    - To compile this driver as a module, choose M here: the
    - module will be called microcode.
    -
    -config MICROCODE_OLD_INTERFACE
    - bool
    - depends on MICROCODE
    - default y
    -
    -config X86_MSR
    - tristate "/dev/cpu/*/msr - Model-specific register support"
    - help
    - This device gives privileged processes access to the x86
    - Model-Specific Registers (MSRs). It is a character device with
    - major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
    - MSR accesses are directed to a specific CPU on multi-processor
    - systems.
    -
    -config X86_CPUID
    - tristate "/dev/cpu/*/cpuid - CPU information support"
    - help
    - This device gives processes access to the x86 CPUID instruction to
    - be executed on a specific processor. It is a character device
    - with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
    - /dev/cpu/31/cpuid.
    -
    -choice
    - prompt "High Memory Support"
    - default HIGHMEM4G if !X86_NUMAQ
    - default HIGHMEM64G if X86_NUMAQ
    - depends on X86_32
    -
    -config NOHIGHMEM
    - bool "off"
    - depends on !X86_NUMAQ
    - ---help---
    - Linux can use up to 64 Gigabytes of physical memory on x86 systems.
    - However, the address space of 32-bit x86 processors is only 4
    - Gigabytes large. That means that, if you have a large amount of
    - physical memory, not all of it can be "permanently mapped" by the
    - kernel. The physical memory that's not permanently mapped is called
    - "high memory".
    -
    - If you are compiling a kernel which will never run on a machine with
    - more than 1 Gigabyte total physical RAM, answer "off" here (default
    - choice and suitable for most users). This will result in a "3GB/1GB"
    - split: 3GB are mapped so that each process sees a 3GB virtual memory
    - space and the remaining part of the 4GB virtual memory space is used
    - by the kernel to permanently map as much physical memory as
    - possible.
    -
    - If the machine has between 1 and 4 Gigabytes physical RAM, then
    - answer "4GB" here.
    -
    - If more than 4 Gigabytes is used then answer "64GB" here. This
    - selection turns Intel PAE (Physical Address Extension) mode on.
    - PAE implements 3-level paging on IA32 processors. PAE is fully
    - supported by Linux, PAE mode is implemented on all recent Intel
    - processors (Pentium Pro and better). NOTE: If you say "64GB" here,
    - then the kernel will not boot on CPUs that don't support PAE!
    -
    - The actual amount of total physical memory will either be
    - auto detected or can be forced by using a kernel command line option
    - such as "mem=256M". (Try "man bootparam" or see the documentation of
    - your boot loader (lilo or loadlin) about how to pass options to the
    - kernel at boot time.)
    -
    - If unsure, say "off".
    -
    -config HIGHMEM4G
    - bool "4GB"
    - depends on !X86_NUMAQ
    - help
    - Select this if you have a 32-bit processor and between 1 and 4
    - gigabytes of physical RAM.
    -
    -config HIGHMEM64G
    - bool "64GB"
    - depends on !M386 && !M486
    - select X86_PAE
    - help
    - Select this if you have a 32-bit processor and more than 4
    - gigabytes of physical RAM.
    -
    -endchoice
    -
    -choice
    - depends on EXPERIMENTAL
    - prompt "Memory split" if EMBEDDED
    - default VMSPLIT_3G
    - depends on X86_32
    - help
    - Select the desired split between kernel and user memory.
    -
    - If the address range available to the kernel is less than the
    - physical memory installed, the remaining memory will be available
    - as "high memory". Accessing high memory is a little more costly
    - than low memory, as it needs to be mapped into the kernel first.
    - Note that increasing the kernel address space limits the range
    - available to user programs, making the address space there
    - tighter. Selecting anything other than the default 3G/1G split
    - will also likely make your kernel incompatible with binary-only
    - kernel modules.
    -
    - If you are not absolutely sure what you are doing, leave this
    - option alone!
    -
    - config VMSPLIT_3G
    - bool "3G/1G user/kernel split"
    - config VMSPLIT_3G_OPT
    - depends on !X86_PAE
    - bool "3G/1G user/kernel split (for full 1G low memory)"
    - config VMSPLIT_2G
    - bool "2G/2G user/kernel split"
    - config VMSPLIT_2G_OPT
    - depends on !X86_PAE
    - bool "2G/2G user/kernel split (for full 2G low memory)"
    - config VMSPLIT_1G
    - bool "1G/3G user/kernel split"
    -endchoice
    -
    -config PAGE_OFFSET
    - hex
    - default 0xB0000000 if VMSPLIT_3G_OPT
    - default 0x80000000 if VMSPLIT_2G
    - default 0x78000000 if VMSPLIT_2G_OPT
    - default 0x40000000 if VMSPLIT_1G
    - default 0xC0000000
    - depends on X86_32
    -
    -config HIGHMEM
    - bool
    - depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
    - default y
    -
    -config X86_PAE
    - bool "PAE (Physical Address Extension) Support"
    - default n
    - depends on X86_32 && !HIGHMEM4G
    - select RESOURCES_64BIT
    - help
    - PAE is required for NX support, and furthermore enables
    - larger swapspace support for non-overcommit purposes. It
    - has the cost of more pagetable lookup overhead, and also
    - consumes more pagetable space per process.
    -
    -# Common NUMA Features
    -config NUMA
    - bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
    - depends on SMP
    - depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
    - default n if X86_PC
    - default y if (X86_NUMAQ || X86_SUMMIT)
    - help
    - Enable NUMA (Non Uniform Memory Access) support.
    - The kernel will try to allocate memory used by a CPU on the
    - local memory controller of the CPU and add some more
    - NUMA awareness to the kernel.
    -
    - For i386 this is currently highly experimental and should be only
    - used for kernel development. It might also cause boot failures.
    - For x86_64 this is recommended on all multiprocessor Opteron systems.
    - If the system is EM64T, you should say N unless your system is
    - EM64T NUMA.
    -
    -comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
    - depends on X86_32 && X86_SUMMIT && (!HIGHMEM64G || !ACPI)
    -
    -config K8_NUMA
    - bool "Old style AMD Opteron NUMA detection"
    - depends on X86_64 && NUMA && PCI
    - default y
    - help
    - Enable K8 NUMA node topology detection. You should say Y here if
    - you have a multi processor AMD K8 system. This uses an old
    - method to read the NUMA configuration directly from the builtin
    - Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
    - instead, which also takes priority if both are compiled in.
    -
    -config X86_64_ACPI_NUMA
    - bool "ACPI NUMA detection"
    - depends on X86_64 && NUMA && ACPI && PCI
    - select ACPI_NUMA
    - default y
    - help
    - Enable ACPI SRAT based node topology detection.
    -
    -config NUMA_EMU
    - bool "NUMA emulation"
    - depends on X86_64 && NUMA
    - help
    - Enable NUMA emulation. A flat machine will be split
    - into virtual nodes when booted with "numa=fake=N", where N is the
    - number of nodes. This is only useful for debugging.
    -
    -config NODES_SHIFT
    - int
    - default "6" if X86_64
    - default "4" if X86_NUMAQ
    - default "3"
    - depends on NEED_MULTIPLE_NODES
    -
    -config HAVE_ARCH_BOOTMEM_NODE
    - bool
    - depends on X86_32 && NUMA
    - default y
    -
    -config ARCH_HAVE_MEMORY_PRESENT
    - bool
    - depends on X86_32 && DISCONTIGMEM
    - default y
    -
    -config NEED_NODE_MEMMAP_SIZE
    - bool
    - depends on X86_32 && (DISCONTIGMEM || SPARSEMEM)
    - default y
    -
    -config HAVE_ARCH_ALLOC_REMAP
    - bool
    - depends on X86_32 && NUMA
    - default y
    -
    -config ARCH_FLATMEM_ENABLE
    - def_bool y
    - depends on (X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC) || (X86_64 && !NUMA)
    -
    -config ARCH_DISCONTIGMEM_ENABLE
    - def_bool y
    - depends on NUMA
    -
    -config ARCH_DISCONTIGMEM_DEFAULT
    - def_bool y
    - depends on NUMA
    -
    -config ARCH_SPARSEMEM_ENABLE
    - def_bool y
    - depends on NUMA || (EXPERIMENTAL && (X86_PC || X86_64))
    - select SPARSEMEM_STATIC if X86_32
    - select SPARSEMEM_VMEMMAP_ENABLE if X86_64
    -
    -config ARCH_SELECT_MEMORY_MODEL
    - def_bool y
    - depends on X86_32 && ARCH_SPARSEMEM_ENABLE
    -
    -config ARCH_MEMORY_PROBE
    - def_bool X86_64
    - depends on MEMORY_HOTPLUG
    -
    -source "mm/Kconfig"
    -
    -config HIGHPTE
    - bool "Allocate 3rd-level pagetables from highmem"
    - depends on X86_32 && (HIGHMEM4G || HIGHMEM64G)
    - help
    - The VM uses one page table entry for each page of physical memory.
    - For systems with a lot of RAM, this can be wasteful of precious
    - low memory. Setting this option will put user-space page table
    - entries in high memory.
    -
    -config MATH_EMULATION
    - bool
    - prompt "Math emulation" if X86_32
    - ---help---
    - Linux can emulate a math coprocessor (used for floating point
    - operations) if you don't have one. 486DX and Pentium processors have
    - a math coprocessor built in, 486SX and 386 do not, unless you added
    - a 487DX or 387, respectively. (The messages during boot time can
    - give you some hints here ["man dmesg"].) Everyone needs either a
    - coprocessor or this emulation.
    -
    - If you don't have a math coprocessor, you need to say Y here; if you
    - say Y here even though you have a coprocessor, the coprocessor will
    - be used nevertheless. (This behavior can be changed with the kernel
    - command line option "no387", which comes handy if your coprocessor
    - is broken. Try "man bootparam" or see the documentation of your boot
    - loader (lilo or loadlin) about how to pass options to the kernel at
    - boot time.) This means that it is a good idea to say Y here if you
    - intend to use this kernel on different machines.
    -
    - More information about the internals of the Linux math coprocessor
    - emulation can be found in <file:arch/x86/math-emu/README>.
    -
    - If you are not sure, say Y; apart from resulting in a 66 KB bigger
    - kernel, it won't hurt.
    -
    -config MTRR
    - bool "MTRR (Memory Type Range Register) support"
    - ---help---
    - On Intel P6 family processors (Pentium Pro, Pentium II and later)
    - the Memory Type Range Registers (MTRRs) may be used to control
    - processor access to memory ranges. This is most useful if you have
    - a video (VGA) card on a PCI or AGP bus. Enabling write-combining
    - allows bus write transfers to be combined into a larger transfer
    - before bursting over the PCI/AGP bus. This can increase performance
    - of image write operations 2.5 times or more. Saying Y here creates a
    - /proc/mtrr file which may be used to manipulate your processor's
    - MTRRs. Typically the X server should use this.
    -
    - This code has a reasonably generic interface so that similar
    - control registers on other processors can be easily supported
    - as well:
    -
    - The Cyrix 6x86, 6x86MX and M II processors have Address Range
    - Registers (ARRs) which provide a similar functionality to MTRRs. For
    - these, the ARRs are used to emulate the MTRRs.
    - The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
    - MTRRs. The Centaur C6 (WinChip) has 8 MCRs, allowing
    - write-combining. All of these processors are supported by this code
    - and it makes sense to say Y here if you have one of them.
    -
    - Saying Y here also fixes a problem with buggy SMP BIOSes which only
    - set the MTRRs for the boot CPU and not for the secondary CPUs. This
    - can lead to all sorts of problems, so it's good to say Y here.
    -
    - You can safely say Y even if your machine doesn't have MTRRs, you'll
    - just add about 9 KB to your kernel.
    -
    - See <file:Documentation/mtrr.txt> for more information.
    -
    -config EFI
    - bool "Boot from EFI support"
    - depends on X86_32 && ACPI
    - default n
    - ---help---
    - This enables the kernel to boot on EFI platforms using
    - system configuration information passed to it from the firmware.
    - This also enables the kernel to use any EFI runtime services that are
    - available (such as the EFI variable services).
    -
    - This option is only useful on systems that have EFI firmware
    - and will result in a kernel image that is ~8k larger. In addition,
    - you must use the latest ELILO loader available at
    - <http://elilo.sourceforge.net> in order to take advantage of
    - kernel initialization using EFI information (neither GRUB nor LILO know
    - anything about EFI). However, even with this option, the resultant
    - kernel should continue to boot on existing non-EFI platforms.
    -
    -config IRQBALANCE
    - bool "Enable kernel irq balancing"
    - depends on X86_32 && SMP && X86_IO_APIC
    - default y
    - help
    - The default yes will allow the kernel to do irq load balancing.
    - Saying no will keep the kernel from doing irq load balancing.
    -
    -# turning this on wastes a bunch of space.
    -# Summit needs it only when NUMA is on
    -config BOOT_IOREMAP
    - bool
    - depends on X86_32 && (((X86_SUMMIT || X86_GENERICARCH) && NUMA) || (X86 && EFI))
    - default y
    -
    -config SECCOMP
    - bool "Enable seccomp to safely compute untrusted bytecode"
    - depends on PROC_FS
    - default y
    - help
    - This kernel feature is useful for number crunching applications
    - that may need to compute untrusted bytecode during their
    - execution. By using pipes or other transports made available to
    - the process as file descriptors supporting the read/write
    - syscalls, it's possible to isolate those applications in
    - their own address space using seccomp. Once seccomp is
    - enabled via /proc/<pid>/seccomp, it cannot be disabled
    - and the task is only allowed to execute a few safe syscalls
    - defined by each seccomp mode.
    -
    - If unsure, say Y. Only embedded should say N here.
    -
    -config CC_STACKPROTECTOR
    - bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
    - depends on X86_64 && EXPERIMENTAL
    - help
    - This option turns on the -fstack-protector GCC feature. This
    - feature puts, at the beginning of critical functions, a canary
    - value on the stack just before the return address, and validates
    - the value just before actually returning. Stack based buffer
    - overflows (that need to overwrite this return address) now also
    - overwrite the canary, which gets detected and the attack is then
    - neutralized via a kernel panic.
    -
    - This feature requires gcc version 4.2 or above, or a distribution
    - gcc with the feature backported. Older versions are automatically
    - detected and for those versions, this configuration option is ignored.
    -
    -config CC_STACKPROTECTOR_ALL
    - bool "Use stack-protector for all functions"
    - depends on CC_STACKPROTECTOR
    - help
    - Normally, GCC only inserts the canary value protection for
    - functions that use large-ish on-stack buffers. By enabling
    - this option, GCC will be asked to do this for ALL functions.
    -
    -source kernel/Kconfig.hz
    -
    -config KEXEC
    - bool "kexec system call"
    - help
    - kexec is a system call that implements the ability to shutdown your
    - current kernel, and to start another kernel. It is like a reboot
    - but it is independent of the system firmware. And like a reboot
    - you can start any kernel with it, not just Linux.
    -
    - The name comes from the similarity to the exec system call.
    -
    - It is an ongoing process to be certain the hardware in a machine
    - is properly shutdown, so do not be surprised if this code does not
    - initially work for you. It may help to enable device hotplugging
    - support. As of this writing the exact hardware interface is
    - strongly in flux, so no good recommendation can be made.
    -
    -config CRASH_DUMP
    - bool "kernel crash dumps (EXPERIMENTAL)"
    - depends on EXPERIMENTAL
    - depends on X86_64 || (X86_32 && HIGHMEM)
    - help
    - Generate crash dump after being started by kexec.
    - This should be normally only set in special crash dump kernels
    - which are loaded in the main kernel with kexec-tools into
    - a specially reserved region and then later executed after
    - a crash by kdump/kexec. The crash dump kernel must be compiled
    - to a memory address not used by the main kernel or BIOS using
    - PHYSICAL_START, or it must be built as a relocatable image
    - (CONFIG_RELOCATABLE=y).
    - For more details see Documentation/kdump/kdump.txt
    -
    -config PHYSICAL_START
    - hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
    - default "0x1000000" if X86_NUMAQ
    - default "0x200000" if X86_64
    - default "0x100000"
    - help
    - This gives the physical address where the kernel is loaded.
    -
    - If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
    - bzImage will decompress itself to above physical address and
    - run from there. Otherwise, bzImage will run from the address where
    - it has been loaded by the boot loader and will ignore above physical
    - address.
    -
    - In normal kdump cases one does not have to set/change this option
    - as now bzImage can be compiled as a completely relocatable image
    - (CONFIG_RELOCATABLE=y) and be used to load and run from a different
    - address. This option is mainly useful for the folks who don't want
    - to use a bzImage for capturing the crash dump and want to use a
    - vmlinux instead. vmlinux is not relocatable hence a kernel needs
    - to be specifically compiled to run from a specific memory area
    - (normally a reserved region) and this option comes handy.
    -
    - So if you are using bzImage for capturing the crash dump, leave
    - the value here unchanged to 0x100000 and set CONFIG_RELOCATABLE=y.
    - Otherwise if you plan to use vmlinux for capturing the crash dump
    - change this value to start of the reserved region (Typically 16MB
    - 0x1000000). In other words, it can be set based on the "X" value as
    - specified in the "crashkernel=YM@XM" command line boot parameter
    - passed to the panic-ed kernel. Typically this parameter is set as
    - crashkernel=64M@16M. Please take a look at
    - Documentation/kdump/kdump.txt for more details about crash dumps.
    -
    - Usage of bzImage for capturing the crash dump is recommended as
    - one does not have to build two kernels. Same kernel can be used
    - as production kernel and capture kernel. Above option should have
    - gone away after relocatable bzImage support is introduced. But it
    - is present because there are users out there who continue to use
    - vmlinux for dump capture. This option should go away down the
    - line.
    -
    - Don't change this unless you know what you are doing.
    -
    -config RELOCATABLE
    - bool "Build a relocatable kernel (EXPERIMENTAL)"
    - depends on EXPERIMENTAL
    - help
    - This builds a kernel image that retains relocation information
    - so it can be loaded someplace besides the default 1MB.
    - The relocations tend to make the kernel binary about 10% larger,
    - but are discarded at runtime.
    -
    - One use is for the kexec on panic case where the recovery kernel
    - must live at a different physical address than the primary
    - kernel.
    -
    - Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
    - it has been loaded at and the compile time physical address
    - (CONFIG_PHYSICAL_START) is ignored.
    -
    -config PHYSICAL_ALIGN
    - hex
    - prompt "Alignment value to which kernel should be aligned" if X86_32
    - default "0x100000" if X86_32
    - default "0x200000" if X86_64
    - range 0x2000 0x400000
    - help
    - This value puts the alignment restrictions on physical address
    - where kernel is loaded and run from. Kernel is compiled for an
    - address which meets above alignment restriction.
    -
    - If bootloader loads the kernel at a non-aligned address and
    - CONFIG_RELOCATABLE is set, kernel will move itself to nearest
    - address aligned to above value and run from there.
    -
    - If bootloader loads the kernel at a non-aligned address and
    - CONFIG_RELOCATABLE is not set, kernel will ignore the run time
    - load address and decompress itself to the address it has been
    - compiled for and run from there. The address for which kernel is
    - compiled already meets above alignment restrictions. Hence the
    - end result is that kernel runs from a physical address meeting
    - above alignment restrictions.
    -
    - Don't change this unless you know what you are doing.
    -
    -config HOTPLUG_CPU
    - bool "Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL)"
    - depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
    - ---help---
    - Say Y here to experiment with turning CPUs off and on, and to
    - enable suspend on SMP systems. CPUs can be controlled through
    - /sys/devices/system/cpu.
    - Say N if you want to disable CPU hotplug and don't need to
    - suspend.
    -
    -config COMPAT_VDSO
    - bool "Compat VDSO support"
    - default y
    - depends on X86_32
    - help
    - Map the VDSO to the predictable old-style address too.
    - ---help---
    - Say N here if you are running a sufficiently recent glibc
    - version (2.3.3 or later), to remove the high-mapped
    - VDSO mapping and to exclusively use the randomized VDSO.
    -
    - If unsure, say Y.
    -
    -endmenu
    -
    -config ARCH_ENABLE_MEMORY_HOTPLUG
    - def_bool y
    - depends on X86_64 || (X86_32 && HIGHMEM)
    -
    -config MEMORY_HOTPLUG_RESERVE
    - def_bool X86_64
    - depends on (MEMORY_HOTPLUG && DISCONTIGMEM)
    -
    -config HAVE_ARCH_EARLY_PFN_TO_NID
    - def_bool X86_64
    - depends on NUMA
    -
    -config OUT_OF_LINE_PFN_TO_PAGE
    - def_bool X86_64
    - depends on DISCONTIGMEM

    source "arch/x86/Kconfig"
    diff --git a/arch/x86/Kconfig.x86_64 b/arch/x86/Kconfig.x86_64
    index e441062..b262aae 100644
    --- a/arch/x86/Kconfig.x86_64
    +++ b/arch/x86/Kconfig.x86_64
    @@ -17,494 +17,4 @@ config X86_64
    classical 32-bit x86 architecture. For details see
    <http://www.x86-64.org/>.

    -source "init/Kconfig"
    -
    -
    -menu "Processor type and features"
    -
    -source "kernel/time/Kconfig"
    -
    -choice
    - prompt "Subarchitecture Type"
    - default X86_PC
    -
    -config X86_PC
    - bool "PC-compatible"
    - help
    - Choose this option if your computer is a standard PC or compatible.
    -
    -config X86_VSMP
    - bool "Support for ScaleMP vSMP"
    - depends on X86_64 && PCI
    - help
    - Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
    - supposed to run on these EM64T-based machines. Only choose this option
    - if you have one of these machines.
    -
    -endchoice
    -
    -source "arch/x86/Kconfig.cpu"
    -
    -config MICROCODE
    - tristate "/dev/cpu/microcode - Intel CPU microcode support"
    - select FW_LOADER
    - ---help---
    - If you say Y here the 'File systems' section, you will be
    - able to update the microcode on Intel processors. You will
    - obviously need the actual microcode binary data itself which is
    - not shipped with the Linux kernel.
    -
    - For latest news and information on obtaining all the required
    - ingredients for this driver, check:
    - <http://www.urbanmyth.org/microcode/>.
    -
    - To compile this driver as a module, choose M here: the
    - module will be called microcode.
    - If you use modprobe or kmod you may also want to add the line
    - 'alias char-major-10-184 microcode' to your /etc/modules.conf file.
    -
    -config MICROCODE_OLD_INTERFACE
    - bool
    - depends on MICROCODE
    - default y
    -
    -config X86_MSR
    - tristate "/dev/cpu/*/msr - Model-specific register support"
    - help
    - This device gives privileged processes access to the x86
    - Model-Specific Registers (MSRs). It is a character device with
    - major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
    - MSR accesses are directed to a specific CPU on multi-processor
    - systems.
    -
    -config X86_CPUID
    - tristate "/dev/cpu/*/cpuid - CPU information support"
    - help
    - This device gives processes access to the x86 CPUID instruction to
    - be executed on a specific processor. It is a character device
    - with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
    - /dev/cpu/31/cpuid.
    -
    -config MATH_EMULATION
    - bool
    -
    -config MCA
    - bool
    -
    -config EISA
    - bool
    -
    -config X86_IO_APIC
    - bool
    - default y
    -
    -config X86_LOCAL_APIC
    - bool
    - default y
    -
    -config MTRR
    - bool "MTRR (Memory Type Range Register) support"
    - ---help---
    - On Intel P6 family processors (Pentium Pro, Pentium II and later)
    - the Memory Type Range Registers (MTRRs) may be used to control
    - processor access to memory ranges. This is most useful if you have
    - a video (VGA) card on a PCI or AGP bus. Enabling write-combining
    - allows bus write transfers to be combined into a larger transfer
    - before bursting over the PCI/AGP bus. This can increase performance
    - of image write operations 2.5 times or more. Saying Y here creates a
    - /proc/mtrr file which may be used to manipulate your processor's
    - MTRRs. Typically the X server should use this.
    -
    - This code has a reasonably generic interface so that similar
    - control registers on other processors can be easily supported
    - as well.
    -
    - Saying Y here also fixes a problem with buggy SMP BIOSes which only
    - set the MTRRs for the boot CPU and not for the secondary CPUs. This
    - can lead to all sorts of problems, so it's good to say Y here.
    -
    - Just say Y here, all x86-64 machines support MTRRs.
    -
    - See <file:Documentation/mtrr.txt> for more information.
    -
    -config SMP
    - bool "Symmetric multi-processing support"
    - ---help---
    - This enables support for systems with more than one CPU. If you have
    - a system with only one CPU, like most personal computers, say N. If
    - you have a system with more than one CPU, say Y.
    -
    - If you say N here, the kernel will run on single and multiprocessor
    - machines, but will use only one CPU of a multiprocessor machine. If
    - you say Y here, the kernel will run on many, but not all,
    - singleprocessor machines. On a singleprocessor machine, the kernel
    - will run faster if you say N here.
    -
    - If you don't know what to do here, say N.
    -
    -config SCHED_SMT
    - bool "SMT (Hyperthreading) scheduler support"
    - depends on SMP
    - default n
    - help
    - SMT scheduler support improves the CPU scheduler's decision making
    - when dealing with Intel Pentium 4 chips with HyperThreading at a
    - cost of slightly increased overhead in some places. If unsure say
    - N here.
    -
    -config SCHED_MC
    - bool "Multi-core scheduler support"
    - depends on SMP
    - default y
    - help
    - Multi-core scheduler support improves the CPU scheduler's decision
    - making when dealing with multi-core CPU chips at a cost of slightly
    - increased overhead in some places. If unsure say N here.
    -
    -source "kernel/Kconfig.preempt"
    -
    -config NUMA
    - bool "Non Uniform Memory Access (NUMA) Support"
    - depends on SMP
    - help
    - Enable NUMA (Non Uniform Memory Access) support. The kernel
    - will try to allocate memory used by a CPU on the local memory
    - controller of the CPU and add some more NUMA awareness to the kernel.
    - This code is recommended on all multiprocessor Opteron systems.
    - If the system is EM64T, you should say N unless your system is EM64T
    - NUMA.
    -
    -config K8_NUMA
    - bool "Old style AMD Opteron NUMA detection"
    - depends on X86_64 && NUMA && PCI
    - default y
    - help
    - Enable K8 NUMA node topology detection. You should say Y here if
    - you have a multi processor AMD K8 system. This uses an old
    - method to read the NUMA configuration directly from the builtin
    - Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
    - instead, which also takes priority if both are compiled in.
    -
    -config NODES_SHIFT
    - int
    - default "6" if X86_64
    - depends on NEED_MULTIPLE_NODES
    -
    -# Dummy CONFIG option to select ACPI_NUMA from drivers/acpi/Kconfig.
    -
    -config X86_64_ACPI_NUMA
    - bool "ACPI NUMA detection"
    - depends on X86_64 && NUMA
    - select ACPI
    - select PCI
    - select ACPI_NUMA
    - default y
    - help
    - Enable ACPI SRAT based node topology detection.
    -
    -config NUMA_EMU
    - bool "NUMA emulation"
    - depends on X86_64 && NUMA
    - help
    - Enable NUMA emulation. A flat machine will be split
    - into virtual nodes when booted with "numa=fake=N", where N is the
    - number of nodes. This is only useful for debugging.
    -
    -config ARCH_DISCONTIGMEM_ENABLE
    - bool
    - depends on NUMA
    - default y
    -
    -config ARCH_DISCONTIGMEM_DEFAULT
    - def_bool y
    - depends on NUMA
    -
    -config ARCH_SPARSEMEM_ENABLE
    - def_bool y
    - depends on (NUMA || EXPERIMENTAL)
    - select SPARSEMEM_VMEMMAP_ENABLE
    -
    -config ARCH_MEMORY_PROBE
    - def_bool X86_64
    - depends on MEMORY_HOTPLUG
    -
    -config ARCH_FLATMEM_ENABLE
    - def_bool y
    - depends on !NUMA
    -
    -source "mm/Kconfig"
    -
    -config MEMORY_HOTPLUG_RESERVE
    - def_bool X86_64
    - depends on (MEMORY_HOTPLUG && DISCONTIGMEM)
    -
    -config HAVE_ARCH_EARLY_PFN_TO_NID
    - def_bool X86_64
    - depends on NUMA
    -
    -config OUT_OF_LINE_PFN_TO_PAGE
    - def_bool X86_64
    - depends on DISCONTIGMEM
    -
    -config NR_CPUS
    - int "Maximum number of CPUs (2-255)"
    - range 2 255
    - depends on SMP
    - default "8"
    - help
    - This allows you to specify the maximum number of CPUs which this
    - kernel will support. Current maximum is 255 CPUs due to
    - APIC addressing limits. Less depending on the hardware.
    -
    - This is purely to save memory - each supported CPU requires
    - memory in the static kernel configuration.
    -
    -config PHYSICAL_ALIGN
    - hex
    - default "0x200000" if X86_64
    -
    -config HOTPLUG_CPU
    - bool "Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL)"
    - depends on SMP && HOTPLUG && EXPERIMENTAL
    - help
    - Say Y here to experiment with turning CPUs off and on. CPUs
    - can be controlled through /sys/devices/system/cpu/cpu#.
    - This is also required for suspend/hibernation on SMP systems.
    -
    - Say N if you want to disable CPU hotplug and don't need to
    - suspend.
    -
    -config ARCH_ENABLE_MEMORY_HOTPLUG
    - def_bool y
    -
    -config HPET_TIMER
    - bool
    - default y
    - help
    - Use the IA-PC HPET (High Precision Event Timer) to manage
    - time in preference to the PIT and RTC, if a HPET is
    - present. The HPET provides a stable time base on SMP
    - systems, unlike the TSC, but it is more expensive to access,
    - as it is off-chip. You can find the HPET spec at
    - <http://www.intel.com/hardwaredesign/hpetspec.htm>.
    -
    -config HPET_EMULATE_RTC
    - bool
    - depends on HPET_TIMER && RTC=y
    - default y
    -
    -# Mark as embedded because too many people got it wrong.
    -# The code disables itself when not needed.
    -config GART_IOMMU
    - bool "GART IOMMU support" if EMBEDDED
    - default y
    - select SWIOTLB
    - select AGP
    - depends on X86_64 && PCI
    - help
    - Support for full DMA access of devices with 32bit memory access only
    - on systems with more than 3GB. This is usually needed for USB,
    - sound, many IDE/SATA chipsets and some other devices.
    - Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
    - based hardware IOMMU and a software bounce buffer based IOMMU used
    - on Intel systems and as fallback.
    - The code is only active when needed (enough memory and limited
    - device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
    - too.
    -
    -config CALGARY_IOMMU
    - bool "IBM Calgary IOMMU support"
    - select SWIOTLB
    - depends on X86_64 && PCI && EXPERIMENTAL
    - help
    - Support for hardware IOMMUs in IBM's xSeries x366 and x460
    - systems. Needed to run systems with more than 3GB of memory
    - properly with 32-bit PCI devices that do not support DAC
    - (Double Address Cycle). Calgary also supports bus level
    - isolation, where all DMAs pass through the IOMMU. This
    - prevents them from going anywhere except their intended
    - destination. This catches hard-to-find kernel bugs and
    - mis-behaving drivers and devices that do not use the DMA-API
    - properly to set up their DMA buffers. The IOMMU can be
    - turned off at boot time with the iommu=off parameter.
    - Normally the kernel will make the right choice by itself.
    - If unsure, say Y.
    -
    -config CALGARY_IOMMU_ENABLED_BY_DEFAULT
    - bool "Should Calgary be enabled by default?"
    - default y
    - depends on CALGARY_IOMMU
    - help
    - Should Calgary be enabled by default? if you choose 'y', Calgary
    - will be used (if it exists). If you choose 'n', Calgary will not be
    - used even if it exists. If you choose 'n' and would like to use
    - Calgary anyway, pass 'iommu=calgary' on the kernel command line.
    - If unsure, say Y.
    -
    -# need this always selected by IOMMU for the VIA workaround
    -config SWIOTLB
    - bool
    - help
    - Support for software bounce buffers used on x86-64 systems
    - which don't have a hardware IOMMU (e.g. the current generation
    - of Intel's x86-64 CPUs). Using this PCI devices which can only
    - access 32-bits of memory can be used on systems with more than
    - 3 GB of memory. If unsure, say Y.
    -
    -config X86_MCE
    - bool "Machine check support" if EMBEDDED
    - default y
    - help
    - Include a machine check error handler to report hardware errors.
    - This version will require the mcelog utility to decode some
    - machine check error logs. See
    - ftp://ftp.x86-64.org/pub/linux/tools/mcelog
    -
    -config X86_MCE_INTEL
    - bool "Intel MCE features"
    - depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    - default y
    - help
    - Additional support for intel specific MCE features such as
    - the thermal monitor.
    -
    -config X86_MCE_AMD
    - bool "AMD MCE features"
    - depends on X86_64 && X86_MCE && X86_LOCAL_APIC
    - default y
    - help
    - Additional support for AMD specific MCE features such as
    - the DRAM Error Threshold.
    -
    -config KEXEC
    - bool "kexec system call"
    - help
    - kexec is a system call that implements the ability to shutdown your
    - current kernel, and to start another kernel. It is like a reboot
    - but it is independent of the system firmware. And like a reboot
    - you can start any kernel with it, not just Linux.
    -
    - The name comes from the similarity to the exec system call.
    -
    - It is an ongoing process to be certain the hardware in a machine
    - is properly shutdown, so do not be surprised if this code does not
    - initially work for you. It may help to enable device hotplugging
    - support. As of this writing the exact hardware interface is
    - strongly in flux, so no good recommendation can be made.
    -
    -config CRASH_DUMP
    - bool "kernel crash dumps (EXPERIMENTAL)"
    - depends on EXPERIMENTAL
    - help
    - Generate crash dump after being started by kexec.
    - This should be normally only set in special crash dump kernels
    - which are loaded in the main kernel with kexec-tools into
    - a specially reserved region and then later executed after
    - a crash by kdump/kexec. The crash dump kernel must be compiled
    - to a memory address not used by the main kernel or BIOS using
    - PHYSICAL_START, or it must be built as a relocatable image
    - (CONFIG_RELOCATABLE=y).
    - For more details see Documentation/kdump/kdump.txt
    -
    -config RELOCATABLE
    - bool "Build a relocatable kernel (EXPERIMENTAL)"
    - depends on EXPERIMENTAL
    - help
    - Builds a relocatable kernel. This enables loading and running
    - a kernel binary from a different physical address than it has
    - been compiled for.
    -
    - One use is for the kexec on panic case where the recovery kernel
    - must live at a different physical address than the primary
    - kernel.
    -
    - Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
    - it has been loaded at and the compile time physical address
    - (CONFIG_PHYSICAL_START) is ignored.
    -
    -config PHYSICAL_START
    - hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
    - default "0x200000"
    - help
    - This gives the physical address where the kernel is loaded. It
    - should be aligned to 2MB boundary.
    -
    - If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
    - bzImage will decompress itself to above physical address and
    - run from there. Otherwise, bzImage will run from the address where
    - it has been loaded by the boot loader and will ignore above physical
    - address.
    -
    - In normal kdump cases one does not have to set/change this option
    - as now bzImage can be compiled as a completely relocatable image
    - (CONFIG_RELOCATABLE=y) and be used to load and run from a different
    - address. This option is mainly useful for the folks who don't want
    - to use a bzImage for capturing the crash dump and want to use a
    - vmlinux instead.
    -
    - So if you are using bzImage for capturing the crash dump, leave
    - the value here unchanged to 0x200000 and set CONFIG_RELOCATABLE=y.
    - Otherwise if you plan to use vmlinux for capturing the crash dump
    - change this value to start of the reserved region (Typically 16MB
    - 0x1000000). In other words, it can be set based on the "X" value as
    - specified in the "crashkernel=YM@XM" command line boot parameter
    - passed to the panic-ed kernel. Typically this parameter is set as
    - crashkernel=64M@16M. Please take a look at
    - Documentation/kdump/kdump.txt for more details about crash dumps.
    -
    - Usage of bzImage for capturing the crash dump is advantageous as
    - one does not have to build two kernels. Same kernel can be used
    - as production kernel and capture kernel.
    -
    - Don't change this unless you know what you are doing.
    -
    -config SECCOMP
    - bool "Enable seccomp to safely compute untrusted bytecode"
    - depends on PROC_FS
    - default y
    - help
    - This kernel feature is useful for number crunching applications
    - that may need to compute untrusted bytecode during their
    - execution. By using pipes or other transports made available to
    - the process as file descriptors supporting the read/write
    - syscalls, it's possible to isolate those applications in
    - their own address space using seccomp. Once seccomp is
    - enabled via /proc/<pid>/seccomp, it cannot be disabled
    - and the task is only allowed to execute a few safe syscalls
    - defined by each seccomp mode.
    -
    - If unsure, say Y. Only embedded should say N here.
    -
    -config CC_STACKPROTECTOR
    - bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
    - depends on X86_64 && EXPERIMENTAL
    - help
    - This option turns on the -fstack-protector GCC feature. This
    - feature puts, at the beginning of critical functions, a canary
    - value on the stack just before the return address, and validates
    - the value just before actually returning. Stack based buffer
    - overflows (that need to overwrite this return address) now also
    - overwrite the canary, which gets detected and the attack is then
    - neutralized via a kernel panic.
    -
    - This feature requires gcc version 4.2 or above, or a distribution
    - gcc with the feature backported. Older versions are automatically
    - detected and for those versions, this configuration option is ignored.
    -
    -config CC_STACKPROTECTOR_ALL
    - bool "Use stack-protector for all functions"
    - depends on CC_STACKPROTECTOR
    - help
    - Normally, GCC only inserts the canary value protection for
    - functions that use large-ish on-stack buffers. By enabling
    - this option, GCC will be asked to do this for ALL functions.
    -
    -source kernel/Kconfig.hz
    -
    -config K8_NB
    - def_bool X86_64
    - depends on AGP_AMD64 || GART_IOMMU || (PCI && NUMA)
    -
    -endmenu
    -
    source "arch/x86/Kconfig"
    --
    1.5.3.4.1157.g0e74-dirty
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-10 00:25    [W:0.187 / U:62.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site