| 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 |