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