2005-04-16 15:20:36 -07:00
|
|
|
# UML uses the generic IRQ sugsystem
|
|
|
|
config GENERIC_HARDIRQS
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
|
|
|
config UML
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
|
|
|
# XXX: does UM have a mmu/swap?
|
|
|
|
config MMU
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
|
|
|
mainmenu "Linux/Usermode Kernel Configuration"
|
|
|
|
|
|
|
|
config ISA
|
|
|
|
bool
|
|
|
|
|
|
|
|
config SBUS
|
|
|
|
bool
|
|
|
|
|
|
|
|
config PCI
|
|
|
|
bool
|
|
|
|
|
|
|
|
config UID16
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
|
|
|
config GENERIC_CALIBRATE_DELAY
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
2005-06-21 17:16:24 -07:00
|
|
|
# Used in kernel/irq/manage.c and include/linux/irq.h
|
|
|
|
config IRQ_RELEASE_METHOD
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
|
[PATCH] uml: reuse i386 cpu-specific tuning
Make UML share the underlying cpu-specific tuning done on i386.
Actually, for now many config options aren't used a lot - but that can be done
later. Also, UML relies on GCC optimization for things like memcpy and such
more than i386, so specifying the correct -march and -mtune should be enough.
Later, we may want to correct some other stuff.
For instance, since FPU context switching, for us, is done (at least
partially, i.e. between our kernelspace and userspace) by the host, we may
allow usage of FPU operations by GCC. This doesn't hold for kernelspace vs.
kernelspace, but we don't support preemption.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 16:00:07 -07:00
|
|
|
menu "Host processor type and features"
|
|
|
|
|
|
|
|
source "arch/i386/Kconfig.cpu"
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
menu "UML-specific options"
|
|
|
|
|
|
|
|
config MODE_TT
|
|
|
|
bool "Tracing thread support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option controls whether tracing thread support is compiled
|
|
|
|
into UML. Normally, this should be set to Y. If you intend to
|
|
|
|
use only skas mode (and the host has the skas patch applied to it),
|
|
|
|
then it is OK to say N here.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
config MODE_SKAS
|
|
|
|
bool "Separate Kernel Address Space support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option controls whether skas (separate kernel address space)
|
|
|
|
support is compiled in. If you have applied the skas patch to the
|
|
|
|
host, then you certainly want to say Y here (and consider saying N
|
|
|
|
to CONFIG_MODE_TT). Otherwise, it is safe to say Y. Disabling this
|
|
|
|
option will shrink the UML binary slightly.
|
|
|
|
|
2005-09-03 15:57:12 -07:00
|
|
|
source "arch/um/Kconfig.arch"
|
2005-06-23 00:07:43 -07:00
|
|
|
source "mm/Kconfig"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
config LD_SCRIPT_STATIC
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
depends on MODE_TT || STATIC_LINK
|
|
|
|
|
|
|
|
config LD_SCRIPT_DYN
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
depends on !LD_SCRIPT_STATIC
|
|
|
|
|
|
|
|
config NET
|
|
|
|
bool "Networking support"
|
|
|
|
help
|
|
|
|
Unless you really know what you are doing, you should say Y here.
|
|
|
|
The reason is that some programs need kernel networking support even
|
|
|
|
when running on a stand-alone machine that isn't connected to any
|
|
|
|
other computer. If you are upgrading from an older kernel, you
|
|
|
|
should consider updating your networking tools too because changes
|
|
|
|
in the kernel and the tools often go hand in hand. The tools are
|
|
|
|
contained in the package net-tools, the location and version number
|
|
|
|
of which are given in <file:Documentation/Changes>.
|
|
|
|
|
|
|
|
For a general introduction to Linux networking, it is highly
|
|
|
|
recommended to read the NET-HOWTO, available from
|
|
|
|
<http://www.tldp.org/docs.html#howto>.
|
|
|
|
|
|
|
|
|
|
|
|
source "fs/Kconfig.binfmt"
|
|
|
|
|
|
|
|
config HOSTFS
|
|
|
|
tristate "Host filesystem"
|
|
|
|
help
|
|
|
|
While the User-Mode Linux port uses its own root file system for
|
|
|
|
booting and normal file access, this module lets the UML user
|
|
|
|
access files stored on the host. It does not require any
|
|
|
|
network connection between the Host and UML. An example use of
|
|
|
|
this might be:
|
|
|
|
|
|
|
|
mount none /tmp/fromhost -t hostfs -o /tmp/umlshare
|
|
|
|
|
|
|
|
where /tmp/fromhost is an empty directory inside UML and
|
|
|
|
/tmp/umlshare is a directory on the host with files the UML user
|
|
|
|
wishes to access.
|
|
|
|
|
|
|
|
For more information, see
|
|
|
|
<http://user-mode-linux.sourceforge.net/hostfs.html>.
|
|
|
|
|
|
|
|
If you'd like to be able to work with files stored on the host,
|
|
|
|
say Y or M here; otherwise say N.
|
|
|
|
|
|
|
|
config HPPFS
|
|
|
|
tristate "HoneyPot ProcFS (EXPERIMENTAL)"
|
|
|
|
help
|
|
|
|
hppfs (HoneyPot ProcFS) is a filesystem which allows UML /proc
|
|
|
|
entries to be overridden, removed, or fabricated from the host.
|
|
|
|
Its purpose is to allow a UML to appear to be a physical machine
|
|
|
|
by removing or changing anything in /proc which gives away the
|
|
|
|
identity of a UML.
|
|
|
|
|
|
|
|
See <http://user-mode-linux.sf.net/hppfs.html> for more information.
|
|
|
|
|
|
|
|
You only need this if you are setting up a UML honeypot. Otherwise,
|
|
|
|
it is safe to say 'N' here.
|
|
|
|
|
2005-07-07 17:56:51 -07:00
|
|
|
If you are actively using it, please report any problems, since it's
|
|
|
|
getting fixed. In this moment, it is experimental on 2.6 (it works on
|
|
|
|
2.4).
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
config MCONSOLE
|
|
|
|
bool "Management console"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
The user mode linux management console is a low-level interface to
|
|
|
|
the kernel, somewhat like the i386 SysRq interface. Since there is
|
|
|
|
a full-blown operating system running under every user mode linux
|
|
|
|
instance, there is much greater flexibility possible than with the
|
|
|
|
SysRq mechanism.
|
|
|
|
|
|
|
|
If you answer 'Y' to this option, to use this feature, you need the
|
|
|
|
mconsole client (called uml_mconsole) which is present in CVS in
|
|
|
|
2.4.5-9um and later (path /tools/mconsole), and is also in the
|
|
|
|
distribution RPM package in 2.4.6 and later.
|
|
|
|
|
|
|
|
It is safe to say 'Y' here.
|
|
|
|
|
|
|
|
config MAGIC_SYSRQ
|
|
|
|
bool "Magic SysRq key"
|
|
|
|
depends on MCONSOLE
|
|
|
|
---help---
|
|
|
|
If you say Y here, you will have some control over the system even
|
|
|
|
if the system crashes for example during kernel debugging (e.g., you
|
|
|
|
will be able to flush the buffer cache to disk, reboot the system
|
|
|
|
immediately or dump some status information). A key for each of the
|
|
|
|
possible requests is provided.
|
|
|
|
|
|
|
|
This is the feature normally accomplished by pressing a key
|
|
|
|
while holding SysRq (Alt+PrintScreen).
|
|
|
|
|
|
|
|
On UML, this is accomplished by sending a "sysrq" command with
|
|
|
|
mconsole, followed by the letter for the requested command.
|
|
|
|
|
|
|
|
The keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
|
|
|
|
unless you really know what this hack does.
|
|
|
|
|
|
|
|
config HOST_2G_2G
|
|
|
|
bool "2G/2G host address space split"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This is needed when the host on which you run has a 2G/2G memory
|
|
|
|
split, instead of the customary 3G/1G.
|
|
|
|
|
|
|
|
Note that to enable such a host
|
|
|
|
configuration, which makes sense only in some cases, you need special
|
|
|
|
host patches.
|
|
|
|
|
|
|
|
So, if you do not know what to do here, say 'N'.
|
|
|
|
|
|
|
|
config SMP
|
|
|
|
bool "Symmetric multi-processing support (EXPERIMENTAL)"
|
|
|
|
default n
|
2005-09-03 15:57:33 -07:00
|
|
|
depends on (MODE_TT && EXPERIMENTAL && !SMP_BROKEN) || (BROKEN && SMP_BROKEN)
|
2005-04-16 15:20:36 -07:00
|
|
|
help
|
|
|
|
This option enables UML SMP support.
|
|
|
|
It is NOT related to having a real SMP box. Not directly, at least.
|
|
|
|
|
|
|
|
UML implements virtual SMP by allowing as many processes to run
|
|
|
|
simultaneously on the host as there are virtual processors configured.
|
|
|
|
|
|
|
|
Obviously, if the host is a uniprocessor, those processes will
|
|
|
|
timeshare, but, inside UML, will appear to be running simultaneously.
|
|
|
|
If the host is a multiprocessor, then UML processes may run
|
|
|
|
simultaneously, depending on the host scheduler.
|
|
|
|
|
|
|
|
This, however, is supported only in TT mode. So, if you use the SKAS
|
|
|
|
patch on your host, switching to TT mode and enabling SMP usually gives
|
|
|
|
you worse performances.
|
|
|
|
Also, since the support for SMP has been under-developed, there could
|
|
|
|
be some bugs being exposed by enabling SMP.
|
|
|
|
|
|
|
|
If you don't know what to do, say N.
|
|
|
|
|
|
|
|
config NR_CPUS
|
|
|
|
int "Maximum number of CPUs (2-32)"
|
|
|
|
range 2 32
|
|
|
|
depends on SMP
|
|
|
|
default "32"
|
|
|
|
|
|
|
|
config NEST_LEVEL
|
|
|
|
int "Nesting level"
|
|
|
|
default "0"
|
|
|
|
help
|
|
|
|
This is set to the number of layers of UMLs that this UML will be run
|
|
|
|
in. Normally, this is zero, meaning that it will run directly on the
|
|
|
|
host. Setting it to one will build a UML that can run inside a UML
|
|
|
|
that is running on the host. Generally, if you intend this UML to run
|
|
|
|
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 KERNEL_HALF_GIGS
|
|
|
|
int "Kernel address space size (in .5G units)"
|
|
|
|
default "1"
|
|
|
|
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 HIGHMEM
|
|
|
|
bool "Highmem support"
|
2005-05-01 08:58:54 -07:00
|
|
|
depends on !64BIT
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
config KERNEL_STACK_ORDER
|
|
|
|
int "Kernel stack size order"
|
|
|
|
default 2
|
|
|
|
help
|
|
|
|
This option determines the size of UML kernel stacks. They will
|
|
|
|
be 1 << order pages. The default is OK unless you're running Valgrind
|
|
|
|
on UML, in which case, set this to 3.
|
|
|
|
|
|
|
|
config UML_REAL_TIME_CLOCK
|
|
|
|
bool "Real-time Clock"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option makes UML time deltas match wall clock deltas. This should
|
|
|
|
normally be enabled. The exception would be if you are debugging with
|
|
|
|
UML and spend long times with UML stopped at a breakpoint. In this
|
|
|
|
case, when UML is restarted, it will call the timer enough times to make
|
|
|
|
up for the time spent at the breakpoint. This could result in a
|
|
|
|
noticable lag. If this is a problem, then disable this option.
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
source "init/Kconfig"
|
|
|
|
|
2005-07-11 21:03:49 -07:00
|
|
|
source "net/Kconfig"
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
source "drivers/base/Kconfig"
|
|
|
|
|
2005-09-03 15:57:12 -07:00
|
|
|
source "arch/um/Kconfig.char"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
source "drivers/block/Kconfig"
|
|
|
|
|
|
|
|
config NETDEVICES
|
|
|
|
bool
|
|
|
|
default NET
|
|
|
|
|
2005-09-03 15:57:12 -07:00
|
|
|
source "arch/um/Kconfig.net"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-07-11 21:03:49 -07:00
|
|
|
source "drivers/net/Kconfig"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
source "fs/Kconfig"
|
|
|
|
|
|
|
|
source "security/Kconfig"
|
|
|
|
|
|
|
|
source "crypto/Kconfig"
|
|
|
|
|
|
|
|
source "lib/Kconfig"
|
|
|
|
|
|
|
|
menu "SCSI support"
|
|
|
|
depends on BROKEN
|
|
|
|
|
|
|
|
config SCSI
|
|
|
|
tristate "SCSI support"
|
|
|
|
|
|
|
|
# This gives us free_dma, which scsi.c wants.
|
|
|
|
config GENERIC_ISA_DMA
|
|
|
|
bool
|
|
|
|
depends on SCSI
|
|
|
|
default y
|
|
|
|
|
2005-09-03 15:57:12 -07:00
|
|
|
source "arch/um/Kconfig.scsi"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
source "drivers/md/Kconfig"
|
|
|
|
|
|
|
|
if BROKEN
|
|
|
|
source "drivers/mtd/Kconfig"
|
|
|
|
endif
|
|
|
|
|
|
|
|
#This is just to shut up some Kconfig warnings, so no prompt.
|
|
|
|
config INPUT
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
source "arch/um/Kconfig.debug"
|