aboutsummaryrefslogtreecommitdiff
path: root/arch/um/Kconfig
diff options
context:
space:
mode:
authorJeff Dike <jdike@addtoit.com>2007-10-16 01:26:50 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-10-16 09:43:05 -0700
commit42fda66387daa53538ae13a2c858396aaf037158 (patch)
tree77955a91a958fde7be47cb0ff23ac9e1248217db /arch/um/Kconfig
parenta1ff5878d2628bbe1e42821c024c96f48318f683 (diff)
uml: throw out CONFIG_MODE_TT
This patchset throws out tt mode, which has been non-functional for a while. This is done in phases, interspersed with code cleanups on the affected files. The removal is done as follows: remove all code, config options, and files which depend on CONFIG_MODE_TT get rid of the CHOOSE_MODE macro, which decided whether to call tt-mode or skas-mode code, and replace invocations with their skas portions replace all now-trivial procedures with their skas equivalents There are now a bunch of now-redundant pieces of data structures, including mode-specific pieces of the thread structure, pt_regs, and mm_context. These are all replaced with their skas-specific contents. As part of the ongoing style compliance project, I made a style pass over all files that were changed. There are three such patches, one for each phase, covering the files affected by that phase but no later ones. I noticed that we weren't freeing the LDT state associated with a process when it exited, so that's fixed in one of the later patches. The last patch is a tidying patch which I've had for a while, but which caused inexplicable crashes under tt mode. Since that is no longer a problem, this can now go in. This patch: Start getting rid of tt mode support. This patch throws out CONFIG_MODE_TT and all config options, code, and files which depend on it. CONFIG_MODE_SKAS is gone and everything that depends on it is included unconditionally. The few changed lines are in re-written Kconfig help, lines which needed something skas-related removed from them, and a few more which weren't strictly deletions. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/um/Kconfig')
-rw-r--r--arch/um/Kconfig64
1 files changed, 10 insertions, 54 deletions
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index e6ff3026654..a0e47e27115 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -62,55 +62,16 @@ config IRQ_RELEASE_METHOD
menu "UML-specific options"
-config MODE_TT
- bool "Tracing thread support (DEPRECATED)"
- default n
- depends on BROKEN
- help
- This option controls whether tracing thread support is compiled
- into UML. This option is largely obsolete, given that skas0 provides
- skas security and performance without needing to patch the host.
- It is safe to say 'N' here; saying 'Y' may cause additional problems
- with the resulting binary even if you run UML in SKAS mode, and running
- in TT mode is strongly *NOT RECOMMENDED*.
-
config STATIC_LINK
bool "Force a static link"
default n
- depends on !MODE_TT
help
- If CONFIG_MODE_TT is disabled, then this option gives you the ability
- to force a static link of UML. Normally, if only skas mode is built
- in to UML, it will be linked as a shared binary. This is inconvenient
- for use in a chroot jail. So, if you intend to run UML inside a
- chroot, and you disable CONFIG_MODE_TT, you probably want to say Y
- here.
+ This option gives you the ability to force a static link of UML.
+ Normally, UML is linked as a shared binary. This is inconvenient for
+ use in a chroot jail. So, if you intend to run UML inside a chroot,
+ you probably want to say Y here.
Additionally, this option enables using higher memory spaces (up to
- 2.75G) for UML - disabling CONFIG_MODE_TT and enabling this option leads
- to best results for this.
-
-config KERNEL_HALF_GIGS
- int "Kernel address space size (in .5G units)"
- default "1"
- depends on MODE_TT
- help
- This determines the amount of address space that UML will allocate for
- its own, measured in half Gigabyte units. The default is 1.
- Change this only if you need to boot UML with an unusually large amount
- of physical memory.
-
-config MODE_SKAS
- bool "Separate Kernel Address Space support" if MODE_TT
- default y
- help
- This option controls whether skas (separate kernel address space)
- support is compiled in.
- Unless you have specific needs to use TT mode (which applies almost only
- to developers), you should say Y here.
- SKAS mode will make use of the SKAS3 patch if it is applied on the host
- (and your UML will run in SKAS3 mode), but if no SKAS patch is applied
- on the host it will run in SKAS0 mode, which is anyway faster than TT
- mode.
+ 2.75G) for UML.
source "arch/um/Kconfig.arch"
source "mm/Kconfig"
@@ -118,7 +79,7 @@ source "mm/Kconfig"
config LD_SCRIPT_STATIC
bool
default y
- depends on MODE_TT || STATIC_LINK
+ depends on STATIC_LINK
config LD_SCRIPT_DYN
bool
@@ -220,7 +181,7 @@ config SMP
bool "Symmetric multi-processing support (EXPERIMENTAL)"
default n
#SMP_BROKEN is for x86_64.
- depends on MODE_TT && EXPERIMENTAL && (!SMP_BROKEN || (BROKEN && SMP_BROKEN))
+ depends on EXPERIMENTAL && (!SMP_BROKEN || (BROKEN && SMP_BROKEN))
help
This option enables UML SMP support.
It is NOT related to having a real SMP box. Not directly, at least.
@@ -258,11 +219,6 @@ config NEST_LEVEL
inside another UML, set CONFIG_NEST_LEVEL to one more than the host
UML.
- Note that if the hosting UML has its CONFIG_KERNEL_HALF_GIGS set to
- greater than one, then the guest UML should have its CONFIG_NEST_LEVEL
- set to the host's CONFIG_NEST_LEVEL + CONFIG_KERNEL_HALF_GIGS.
- Only change this if you are running nested UMLs.
-
config HIGHMEM
bool "Highmem support (EXPERIMENTAL)"
depends on !64BIT && EXPERIMENTAL
@@ -271,9 +227,9 @@ config HIGHMEM
This was used to allow UML to run with big amounts of memory.
Currently it is unstable, so if unsure say N.
- To use big amounts of memory, it is recommended to disable TT mode (i.e.
- CONFIG_MODE_TT) and enable static linking (i.e. CONFIG_STATIC_LINK) -
- this should allow the guest to use up to 2.75G of memory.
+ To use big amounts of memory, it is recommended enable static
+ linking (i.e. CONFIG_STATIC_LINK) - this should allow the
+ guest to use up to 2.75G of memory.
config KERNEL_STACK_ORDER
int "Kernel stack size order"