linux/arch/sparc64/Kconfig

434 lines
9.0 KiB
Plaintext
Raw Normal View History

# sparc64 configuration
mainmenu "Linux Kernel Configuration for 64-bit SPARC"
config SPARC
bool
default y
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
config SPARC64
bool
default y
select HAVE_FUNCTION_TRACER
select HAVE_IDE
select HAVE_LMB
select HAVE_ARCH_KGDB
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_ARCH_TRACEHOOK
select ARCH_WANT_OPTIONAL_GPIOLIB
select RTC_CLASS
select RTC_DRV_M48T59
select RTC_DRV_CMOS
select RTC_DRV_BQ4802
select RTC_DRV_SUN4V
select RTC_DRV_STARFIRE
config GENERIC_TIME
bool
default y
config GENERIC_CMOS_UPDATE
bool
default y
config GENERIC_CLOCKEVENTS
bool
default y
config GENERIC_GPIO
bool
help
Generic GPIO API support
config 64BIT
def_bool y
config MMU
bool
default y
config IOMMU_HELPER
bool
default y
config QUICKLIST
bool
default y
config STACKTRACE_SUPPORT
bool
default y
config LOCKDEP_SUPPORT
bool
default y
config ARCH_MAY_HAVE_PC_FDC
bool
default y
config ARCH_HAS_ILOG2_U32
bool
default n
config ARCH_HAS_ILOG2_U64
bool
default n
config AUDIT_ARCH
bool
default y
config HAVE_SETUP_PER_CPU_AREA
def_bool y
config ARCH_NO_VIRT_TO_BUS
def_bool y
config OF
def_bool y
config GENERIC_HARDIRQS_NO__DO_IRQ
bool
def_bool y
source "init/Kconfig"
container freezer: implement freezer cgroup subsystem This patch implements a new freezer subsystem in the control groups framework. It provides a way to stop and resume execution of all tasks in a cgroup by writing in the cgroup filesystem. The freezer subsystem in the container filesystem defines a file named freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the cgroup. Subsequently writing "RUNNING" will unfreeze the tasks in the cgroup. Reading will return the current state. * Examples of usage : # mkdir /containers/freezer # mount -t cgroup -ofreezer freezer /containers # mkdir /containers/0 # echo $some_pid > /containers/0/tasks to get status of the freezer subsystem : # cat /containers/0/freezer.state RUNNING to freeze all tasks in the container : # echo FROZEN > /containers/0/freezer.state # cat /containers/0/freezer.state FREEZING # cat /containers/0/freezer.state FROZEN to unfreeze all tasks in the container : # echo RUNNING > /containers/0/freezer.state # cat /containers/0/freezer.state RUNNING This is the basic mechanism which should do the right thing for user space task in a simple scenario. It's important to note that freezing can be incomplete. In that case we return EBUSY. This means that some tasks in the cgroup are busy doing something that prevents us from completely freezing the cgroup at this time. After EBUSY, the cgroup will remain partially frozen -- reflected by freezer.state reporting "FREEZING" when read. The state will remain "FREEZING" until one of these things happens: 1) Userspace cancels the freezing operation by writing "RUNNING" to the freezer.state file 2) Userspace retries the freezing operation by writing "FROZEN" to the freezer.state file (writing "FREEZING" is not legal and returns EIO) 3) The tasks that blocked the cgroup from entering the "FROZEN" state disappear from the cgroup's set of tasks. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: export thaw_process] Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> Acked-by: Serge E. Hallyn <serue@us.ibm.com> Tested-by: Matt Helsley <matthltc@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-19 11:27:21 +08:00
source "kernel/Kconfig.freezer"
menu "Processor type and features"
choice
prompt "Kernel page size"
default SPARC64_PAGE_SIZE_8KB
config SPARC64_PAGE_SIZE_8KB
bool "8KB"
help
This lets you select the page size of the kernel.
8KB and 64KB work quite well, since SPARC ELF sections
provide for up to 64KB alignment.
If you don't know what to do, choose 8KB.
config SPARC64_PAGE_SIZE_64KB
bool "64KB"
endchoice
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.
source kernel/Kconfig.hz
[SPARC64]: Initial LDOM cpu hotplug support. Only adding cpus is supports at the moment, removal will come next. When new cpus are configured, the machine description is updated. When we get the configure request we pass in a cpu mask of to-be-added cpus to the mdesc CPU node parser so it only fetches information for those cpus. That code also proceeds to update the SMT/multi-core scheduling bitmaps. cpu_up() does all the work and we return the status back over the DS channel. CPUs via dr-cpu need to be booted straight out of the hypervisor, and this requires: 1) A new trampoline mechanism. CPUs are booted straight out of the hypervisor with MMU disabled and running in physical addresses with no mappings installed in the TLB. The new hvtramp.S code sets up the critical cpu state, installs the locked TLB mappings for the kernel, and turns the MMU on. It then proceeds to follow the logic of the existing trampoline.S SMP cpu bringup code. 2) All calls into OBP have to be disallowed when domaining is enabled. Since cpus boot straight into the kernel from the hypervisor, OBP has no state about that cpu and therefore cannot handle being invoked on that cpu. Luckily it's only a handful of interfaces which can be called after the OBP device tree is obtained. For example, rebooting, halting, powering-off, and setting options node variables. CPU removal support will require some infrastructure changes here. Namely we'll have to process the requests via a true kernel thread instead of in a workqueue. workqueues run on a per-cpu thread, but when unconfiguring we might need to force the thread to execute on another cpu if the current cpu is the one being removed. Removal of a cpu also causes the kernel to destroy that cpu's workqueue running thread. Another issue on removal is that we may have interrupts still pointing to the cpu-to-be-removed. So new code will be needed to walk the active INO list and retarget those cpus as-needed. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-14 07:03:42 +08:00
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
select HOTPLUG
help
[SPARC64]: Initial LDOM cpu hotplug support. Only adding cpus is supports at the moment, removal will come next. When new cpus are configured, the machine description is updated. When we get the configure request we pass in a cpu mask of to-be-added cpus to the mdesc CPU node parser so it only fetches information for those cpus. That code also proceeds to update the SMT/multi-core scheduling bitmaps. cpu_up() does all the work and we return the status back over the DS channel. CPUs via dr-cpu need to be booted straight out of the hypervisor, and this requires: 1) A new trampoline mechanism. CPUs are booted straight out of the hypervisor with MMU disabled and running in physical addresses with no mappings installed in the TLB. The new hvtramp.S code sets up the critical cpu state, installs the locked TLB mappings for the kernel, and turns the MMU on. It then proceeds to follow the logic of the existing trampoline.S SMP cpu bringup code. 2) All calls into OBP have to be disallowed when domaining is enabled. Since cpus boot straight into the kernel from the hypervisor, OBP has no state about that cpu and therefore cannot handle being invoked on that cpu. Luckily it's only a handful of interfaces which can be called after the OBP device tree is obtained. For example, rebooting, halting, powering-off, and setting options node variables. CPU removal support will require some infrastructure changes here. Namely we'll have to process the requests via a true kernel thread instead of in a workqueue. workqueues run on a per-cpu thread, but when unconfiguring we might need to force the thread to execute on another cpu if the current cpu is the one being removed. Removal of a cpu also causes the kernel to destroy that cpu's workqueue running thread. Another issue on removal is that we may have interrupts still pointing to the cpu-to-be-removed. So new code will be needed to walk the active INO list and retarget those cpus as-needed. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-14 07:03:42 +08:00
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu/cpu#.
Say N if you want to disable CPU hotplug.
config GENERIC_HARDIRQS
bool
default y
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, 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 single-processor machines.
On a single-processor machine, the kernel will run faster if you say
N here.
If you don't know what to do here, say N.
config NR_CPUS
int "Maximum number of CPUs (2-1024)"
range 2 1024
depends on SMP
default "64"
source "drivers/cpufreq/Kconfig"
config US3_FREQ
tristate "UltraSPARC-III CPU Frequency driver"
depends on CPU_FREQ
select CPU_FREQ_TABLE
help
This adds the CPUFreq driver for UltraSPARC-III processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
config US2E_FREQ
tristate "UltraSPARC-IIe CPU Frequency driver"
depends on CPU_FREQ
select CPU_FREQ_TABLE
help
This adds the CPUFreq driver for UltraSPARC-IIe processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
config US3_MC
tristate "UltraSPARC-III Memory Controller driver"
default y
help
This adds a driver for the UltraSPARC-III memory controller.
Loading this driver allows exact mnemonic strings to be
printed in the event of a memory error, so that the faulty DIMM
on the motherboard can be matched to the error.
If in doubt, say Y, as this information can be very useful.
# Global things across all Sun machines.
config GENERIC_LOCKBREAK
bool
default y
depends on SMP && PREEMPT
config RWSEM_GENERIC_SPINLOCK
bool
config RWSEM_XCHGADD_ALGORITHM
bool
default y
config GENERIC_FIND_NEXT_BIT
bool
default y
config GENERIC_HWEIGHT
bool
default y if !ULTRA_HAS_POPULATION_COUNT
config GENERIC_CALIBRATE_DELAY
bool
default y
choice
prompt "SPARC64 Huge TLB Page Size"
depends on HUGETLB_PAGE
default HUGETLB_PAGE_SIZE_4MB
config HUGETLB_PAGE_SIZE_4MB
bool "4MB"
config HUGETLB_PAGE_SIZE_512K
bool "512K"
config HUGETLB_PAGE_SIZE_64K
depends on !SPARC64_PAGE_SIZE_64KB
bool "64K"
endchoice
endmenu
config NUMA
bool "NUMA support"
depends on SMP
config NODES_SHIFT
int
default "4"
depends on NEED_MULTIPLE_NODES
# Some NUMA nodes have memory ranges that span
# other nodes. Even though a pfn is valid and
# between a node's start and end pfns, it may not
# reside on that node. See memmap_init_zone()
# for details.
config NODES_SPAN_OTHER_NODES
def_bool y
depends on NEED_MULTIPLE_NODES
config ARCH_POPULATES_NODE_MAP
def_bool y
config ARCH_SELECT_MEMORY_MODEL
def_bool y
config ARCH_SPARSEMEM_ENABLE
def_bool y
select SPARSEMEM_VMEMMAP_ENABLE
config ARCH_SPARSEMEM_DEFAULT
def_bool y
source "mm/Kconfig"
config ISA
bool
config ISAPNP
bool
config EISA
bool
config MCA
bool
config PCMCIA
tristate
help
Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
computer. These are credit-card size devices such as network cards,
modems or hard drives often used with laptops computers. There are
actually two varieties of these cards: the older 16 bit PCMCIA cards
and the newer 32 bit CardBus cards. If you want to use CardBus
cards, you need to say Y here and also to "CardBus support" below.
To use your PC-cards, you will need supporting software from David
Hinds' pcmcia-cs package (see the file <file:Documentation/Changes>
for location). Please also read the PCMCIA-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
To compile this driver as modules, choose M here: the
modules will be called pcmcia_core and ds.
config SBUS
bool
default y
config SBUSCHAR
bool
default y
config SUN_AUXIO
bool
default y
config SUN_IO
bool
default y
config SUN_LDOMS
bool "Sun Logical Domains support"
help
Say Y here is you want to support virtual devices via
Logical Domains.
config PCI
bool "PCI support"
select ARCH_SUPPORTS_MSI
help
Find out whether your system includes a PCI bus. PCI is the name of
a bus system, i.e. the way the CPU talks to the other stuff inside
your box. If you say Y here, the kernel will include drivers and
infrastructure code to support PCI bus devices.
config PCI_DOMAINS
def_bool PCI
config PCI_SYSCALL
def_bool PCI
source "drivers/pci/Kconfig"
config SUN_OPENPROMFS
tristate "Openprom tree appears in /proc/openprom"
help
If you say Y, the OpenPROM device tree will be available as a
virtual file system, which you can mount to /proc/openprom by "mount
-t openpromfs none /proc/openprom".
To compile the /proc/openprom support as a module, choose M here: the
module will be called openpromfs. If unsure, choose M.
menu "Executable file formats"
source "fs/Kconfig.binfmt"
config COMPAT
bool
default y
select COMPAT_BINFMT_ELF
config SYSVIPC_COMPAT
bool
depends on COMPAT && SYSVIPC
default y
endmenu
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on SMP
default y
help
SMT scheduler support improves the CPU scheduler's decision making
when dealing with SPARC cpus 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 CMDLINE_BOOL
bool "Default bootloader kernel arguments"
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
default "console=ttyS0,9600 root=/dev/sda1"
help
Say Y here if you want to be able to pass default arguments to
the kernel. This will be overridden by the bootloader, if you
use one (such as SILO). This is most useful if you want to boot
a kernel from TFTP, and want default options to be available
with having them passed on the command line.
NOTE: This option WILL override the PROM bootargs setting!
source "net/Kconfig"
source "drivers/Kconfig"
source "drivers/sbus/char/Kconfig"
source "fs/Kconfig"
source "arch/sparc64/Kconfig.debug"
source "security/Kconfig"
source "crypto/Kconfig"
source "lib/Kconfig"