|  |  | 
|  | 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/old/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. | 
|  | 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)" | 
|  | depends on BLOCK | 
|  | 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. | 
|  |  | 
|  | Applications should preferably 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 SOUND_OSS_CORE | 
|  | bool | 
|  | 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 |