239 строки
8.5 KiB
Plaintext
239 строки
8.5 KiB
Plaintext
|
|
menu "Character Devices"
|
|
|
|
config STDERR_CONSOLE
|
|
bool "stderr console"
|
|
default y
|
|
help
|
|
console driver which dumps all printk messages to stderr.
|
|
|
|
config STDIO_CONSOLE
|
|
bool
|
|
default y
|
|
|
|
config SSL
|
|
bool "Virtual serial line"
|
|
help
|
|
The User-Mode Linux environment allows you to create virtual serial
|
|
lines on the UML that are usually made to show up on the host as
|
|
ttys or ptys.
|
|
|
|
See <http://user-mode-linux.sourceforge.net/input.html> for more
|
|
information and command line examples of how to use this facility.
|
|
|
|
Unless you have a specific reason for disabling this, say Y.
|
|
|
|
config NULL_CHAN
|
|
bool "null channel support"
|
|
help
|
|
This option enables support for attaching UML consoles and serial
|
|
lines to a device similar to /dev/null. Data written to it disappears
|
|
and there is never any data to be read.
|
|
|
|
config PORT_CHAN
|
|
bool "port channel support"
|
|
help
|
|
This option enables support for attaching UML consoles and serial
|
|
lines to host portals. They may be accessed with 'telnet <host>
|
|
<port number>'. Any number of consoles and serial lines may be
|
|
attached to a single portal, although what UML device you get when
|
|
you telnet to that portal will be unpredictable.
|
|
It is safe to say 'Y' here.
|
|
|
|
config PTY_CHAN
|
|
bool "pty channel support"
|
|
help
|
|
This option enables support for attaching UML consoles and serial
|
|
lines to host pseudo-terminals. Access to both traditional
|
|
pseudo-terminals (/dev/pty*) and pts pseudo-terminals are controlled
|
|
with this option. The assignment of UML devices to host devices
|
|
will be announced in the kernel message log.
|
|
It is safe to say 'Y' here.
|
|
|
|
config TTY_CHAN
|
|
bool "tty channel support"
|
|
help
|
|
This option enables support for attaching UML consoles and serial
|
|
lines to host terminals. Access to both virtual consoles
|
|
(/dev/tty*) and the slave side of pseudo-terminals (/dev/ttyp* and
|
|
/dev/pts/*) are controlled by this option.
|
|
It is safe to say 'Y' here.
|
|
|
|
config XTERM_CHAN
|
|
bool "xterm channel support"
|
|
help
|
|
This option enables support for attaching UML consoles and serial
|
|
lines to xterms. Each UML device so assigned will be brought up in
|
|
its own xterm.
|
|
If you disable this option, then CONFIG_PT_PROXY will be disabled as
|
|
well, since UML's gdb currently requires an xterm.
|
|
It is safe to say 'Y' here.
|
|
|
|
config NOCONFIG_CHAN
|
|
bool
|
|
default !(XTERM_CHAN && TTY_CHAN && PTY_CHAN && PORT_CHAN && NULL_CHAN)
|
|
|
|
config CON_ZERO_CHAN
|
|
string "Default main console channel initialization"
|
|
default "fd:0,fd:1"
|
|
help
|
|
This is the string describing the channel to which the main console
|
|
will be attached by default. This value can be overridden from the
|
|
command line. The default value is "fd:0,fd:1", which attaches the
|
|
main console to stdin and stdout.
|
|
It is safe to leave this unchanged.
|
|
|
|
config CON_CHAN
|
|
string "Default console channel initialization"
|
|
default "xterm"
|
|
help
|
|
This is the string describing the channel to which all consoles
|
|
except the main console will be attached by default. This value can
|
|
be overridden from the command line. The default value is "xterm",
|
|
which brings them up in xterms.
|
|
It is safe to leave this unchanged, although you may wish to change
|
|
this if you expect the UML that you build to be run in environments
|
|
which don't have X or xterm available.
|
|
|
|
config SSL_CHAN
|
|
string "Default serial line channel initialization"
|
|
default "pty"
|
|
help
|
|
This is the string describing the channel to which the serial lines
|
|
will be attached by default. This value can be overridden from the
|
|
command line. The default value is "pty", which attaches them to
|
|
traditional pseudo-terminals.
|
|
It is safe to leave this unchanged, although you may wish to change
|
|
this if you expect the UML that you build to be run in environments
|
|
which don't have a set of /dev/pty* devices.
|
|
|
|
config UNIX98_PTYS
|
|
bool "Unix98 PTY support"
|
|
---help---
|
|
A pseudo terminal (PTY) is a software device consisting of two
|
|
halves: a master and a slave. The slave device behaves identical to
|
|
a physical terminal; the master device is used by a process to
|
|
read data from and write data to the slave, thereby emulating a
|
|
terminal. Typical programs for the master side are telnet servers
|
|
and xterms.
|
|
|
|
Linux has traditionally used the BSD-like names /dev/ptyxx for
|
|
masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
|
|
has a number of problems. The GNU C library glibc 2.1 and later,
|
|
however, supports the Unix98 naming standard: in order to acquire a
|
|
pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
|
|
terminal is then made available to the process and the pseudo
|
|
terminal slave can be accessed as /dev/pts/<number>. What was
|
|
traditionally /dev/ttyp2 will then be /dev/pts/2, for example.
|
|
|
|
All modern Linux systems use the Unix98 ptys. Say Y unless
|
|
you're on an embedded system and want to conserve memory.
|
|
|
|
config LEGACY_PTYS
|
|
bool "Legacy (BSD) PTY support"
|
|
default y
|
|
---help---
|
|
A pseudo terminal (PTY) is a software device consisting of two
|
|
halves: a master and a slave. The slave device behaves identical to
|
|
a physical terminal; the master device is used by a process to
|
|
read data from and write data to the slave, thereby emulating a
|
|
terminal. Typical programs for the master side are telnet servers
|
|
and xterms.
|
|
|
|
Linux has traditionally used the BSD-like names /dev/ptyxx
|
|
for masters and /dev/ttyxx for slaves of pseudo
|
|
terminals. This scheme has a number of problems, including
|
|
security. This option enables these legacy devices; on most
|
|
systems, it is safe to say N.
|
|
|
|
config RAW_DRIVER
|
|
tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
|
|
help
|
|
The raw driver permits block devices to be bound to /dev/raw/rawN.
|
|
Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
|
|
See the raw(8) manpage for more details.
|
|
|
|
The raw driver is deprecated and will be removed soon.
|
|
Applications should simply open the device (eg /dev/hda1)
|
|
with the O_DIRECT flag.
|
|
|
|
config MAX_RAW_DEVS
|
|
int "Maximum number of RAW devices to support (1-8192)"
|
|
depends on RAW_DRIVER
|
|
default "256"
|
|
help
|
|
The maximum number of RAW devices that are supported.
|
|
Default is 256. Increase this number in case you need lots of
|
|
raw devices.
|
|
|
|
config LEGACY_PTY_COUNT
|
|
int "Maximum number of legacy PTY in use"
|
|
depends on LEGACY_PTYS
|
|
default "256"
|
|
---help---
|
|
The maximum number of legacy PTYs that can be used at any one time.
|
|
The default is 256, and should be more than enough. Embedded
|
|
systems may want to reduce this to save memory.
|
|
|
|
When not in use, each legacy PTY occupies 12 bytes on 32-bit
|
|
architectures and 24 bytes on 64-bit architectures.
|
|
|
|
config WATCHDOG
|
|
bool "Watchdog Timer Support"
|
|
|
|
config WATCHDOG_NOWAYOUT
|
|
bool "Disable watchdog shutdown on close"
|
|
depends on WATCHDOG
|
|
|
|
config SOFT_WATCHDOG
|
|
tristate "Software Watchdog"
|
|
depends on WATCHDOG
|
|
|
|
config UML_WATCHDOG
|
|
tristate "UML watchdog"
|
|
depends on WATCHDOG
|
|
|
|
config UML_SOUND
|
|
tristate "Sound support"
|
|
help
|
|
This option enables UML sound support. If enabled, it will pull in
|
|
soundcore and the UML hostaudio relay, which acts as a intermediary
|
|
between the host's dsp and mixer devices and the UML sound system.
|
|
It is safe to say 'Y' here.
|
|
|
|
config SOUND
|
|
tristate
|
|
default UML_SOUND
|
|
|
|
config HOSTAUDIO
|
|
tristate
|
|
default UML_SOUND
|
|
|
|
#It is selected elsewhere, so kconfig would warn without this.
|
|
config HW_RANDOM
|
|
tristate
|
|
default n
|
|
|
|
config UML_RANDOM
|
|
tristate "Hardware random number generator"
|
|
help
|
|
This option enables UML's "hardware" random number generator. It
|
|
attaches itself to the host's /dev/random, supplying as much entropy
|
|
as the host has, rather than the small amount the UML gets from its
|
|
own drivers. It registers itself as a standard hardware random number
|
|
generator, major 10, minor 183, and the canonical device name is
|
|
/dev/hwrng.
|
|
The way to make use of this is to install the rng-tools package
|
|
(check your distro, or download from
|
|
http://sourceforge.net/projects/gkernel/). rngd periodically reads
|
|
/dev/hwrng and injects the entropy into /dev/random.
|
|
|
|
config MMAPPER
|
|
tristate "iomem emulation driver"
|
|
help
|
|
This driver allows a host file to be used as emulated IO memory inside
|
|
UML.
|
|
|
|
endmenu
|
|
|