home *** CD-ROM | disk | FTP | other *** search
/ PC Welt 2006 November (DVD) / PCWELT_11_2006.ISO / casper / filesystem.squashfs / usr / src / linux-headers-2.6.17-6 / arch / um / Kconfig.char next >
Encoding:
Text File  |  2006-08-11  |  7.6 KB  |  215 lines

  1.  
  2. menu "Character Devices"
  3.  
  4. config STDERR_CONSOLE
  5.     bool "stderr console"
  6.     default y
  7.     help
  8.     console driver which dumps all printk messages to stderr.
  9.  
  10. config STDIO_CONSOLE
  11.     bool
  12.     default y
  13.  
  14. config SSL
  15.     bool "Virtual serial line"
  16.     help
  17.         The User-Mode Linux environment allows you to create virtual serial
  18.         lines on the UML that are usually made to show up on the host as
  19.         ttys or ptys.
  20.  
  21.         See <http://user-mode-linux.sourceforge.net/input.html> for more
  22.         information and command line examples of how to use this facility.
  23.  
  24.         Unless you have a specific reason for disabling this, say Y.
  25.  
  26. config NULL_CHAN
  27.     bool "null channel support"
  28.     help
  29.         This option enables support for attaching UML consoles and serial
  30.         lines to a device similar to /dev/null.  Data written to it disappears
  31.         and there is never any data to be read.
  32.  
  33. config PORT_CHAN
  34.     bool "port channel support"
  35.     help
  36.         This option enables support for attaching UML consoles and serial
  37.         lines to host portals.  They may be accessed with 'telnet <host>
  38.         <port number>'.  Any number of consoles and serial lines may be
  39.         attached to a single portal, although what UML device you get when
  40.         you telnet to that portal will be unpredictable.
  41.         It is safe to say 'Y' here.
  42.  
  43. config PTY_CHAN
  44.     bool "pty channel support"
  45.     help
  46.         This option enables support for attaching UML consoles and serial
  47.         lines to host pseudo-terminals.  Access to both traditional
  48.         pseudo-terminals (/dev/pty*) and pts pseudo-terminals are controlled
  49.         with this option.  The assignment of UML devices to host devices
  50.         will be announced in the kernel message log.
  51.         It is safe to say 'Y' here.
  52.  
  53. config TTY_CHAN
  54.     bool "tty channel support"
  55.     help
  56.         This option enables support for attaching UML consoles and serial
  57.         lines to host terminals.  Access to both virtual consoles
  58.         (/dev/tty*) and the slave side of pseudo-terminals (/dev/ttyp* and
  59.         /dev/pts/*) are controlled by this option.
  60.         It is safe to say 'Y' here.
  61.  
  62. config XTERM_CHAN
  63.     bool "xterm channel support"
  64.     help
  65.         This option enables support for attaching UML consoles and serial
  66.         lines to xterms.  Each UML device so assigned will be brought up in
  67.         its own xterm.
  68.         If you disable this option, then CONFIG_PT_PROXY will be disabled as
  69.         well, since UML's gdb currently requires an xterm.
  70.         It is safe to say 'Y' here.
  71.  
  72. config NOCONFIG_CHAN
  73.     bool
  74.     default !(XTERM_CHAN && TTY_CHAN && PTY_CHAN && PORT_CHAN && NULL_CHAN)
  75.  
  76. config CON_ZERO_CHAN
  77.     string "Default main console channel initialization"
  78.     default "fd:0,fd:1"
  79.     help
  80.         This is the string describing the channel to which the main console
  81.         will be attached by default.  This value can be overridden from the
  82.         command line.  The default value is "fd:0,fd:1", which attaches the
  83.         main console to stdin and stdout.
  84.         It is safe to leave this unchanged.
  85.  
  86. config CON_CHAN
  87.     string "Default console channel initialization"
  88.     default "xterm"
  89.     help
  90.         This is the string describing the channel to which all consoles
  91.         except the main console will be attached by default.  This value can
  92.         be overridden from the command line.  The default value is "xterm",
  93.         which brings them up in xterms.
  94.         It is safe to leave this unchanged, although you may wish to change
  95.         this if you expect the UML that you build to be run in environments
  96.         which don't have X or xterm available.
  97.  
  98. config SSL_CHAN
  99.     string "Default serial line channel initialization"
  100.     default "pty"
  101.     help
  102.         This is the string describing the channel to which the serial lines
  103.         will be attached by default.  This value can be overridden from the
  104.         command line.  The default value is "pty", which attaches them to
  105.         traditional pseudo-terminals.
  106.         It is safe to leave this unchanged, although you may wish to change
  107.         this if you expect the UML that you build to be run in environments
  108.         which don't have a set of /dev/pty* devices.
  109.  
  110. config UNIX98_PTYS
  111.     bool "Unix98 PTY support"
  112.     ---help---
  113.       A pseudo terminal (PTY) is a software device consisting of two
  114.       halves: a master and a slave. The slave device behaves identical to
  115.       a physical terminal; the master device is used by a process to
  116.       read data from and write data to the slave, thereby emulating a
  117.       terminal. Typical programs for the master side are telnet servers
  118.       and xterms.
  119.  
  120.       Linux has traditionally used the BSD-like names /dev/ptyxx for
  121.       masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
  122.       has a number of problems. The GNU C library glibc 2.1 and later,
  123.       however, supports the Unix98 naming standard: in order to acquire a
  124.       pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
  125.       terminal is then made available to the process and the pseudo
  126.       terminal slave can be accessed as /dev/pts/<number>. What was
  127.       traditionally /dev/ttyp2 will then be /dev/pts/2, for example.
  128.  
  129.       All modern Linux systems use the Unix98 ptys.  Say Y unless
  130.       you're on an embedded system and want to conserve memory.
  131.  
  132. config LEGACY_PTYS
  133.     bool "Legacy (BSD) PTY support"
  134.     default y
  135.     ---help---
  136.       A pseudo terminal (PTY) is a software device consisting of two
  137.       halves: a master and a slave. The slave device behaves identical to
  138.       a physical terminal; the master device is used by a process to
  139.       read data from and write data to the slave, thereby emulating a
  140.       terminal. Typical programs for the master side are telnet servers
  141.       and xterms.
  142.  
  143.       Linux has traditionally used the BSD-like names /dev/ptyxx
  144.       for masters and /dev/ttyxx for slaves of pseudo
  145.       terminals. This scheme has a number of problems, including
  146.       security.  This option enables these legacy devices; on most
  147.       systems, it is safe to say N.
  148.  
  149.  
  150. config LEGACY_PTY_COUNT
  151.     int "Maximum number of legacy PTY in use"
  152.     depends on LEGACY_PTYS
  153.     default "256"
  154.     ---help---
  155.       The maximum number of legacy PTYs that can be used at any one time.
  156.       The default is 256, and should be more than enough.  Embedded
  157.       systems may want to reduce this to save memory.
  158.  
  159.       When not in use, each legacy PTY occupies 12 bytes on 32-bit
  160.       architectures and 24 bytes on 64-bit architectures.
  161.  
  162. config WATCHDOG
  163.     bool "Watchdog Timer Support"
  164.  
  165. config WATCHDOG_NOWAYOUT
  166.     bool "Disable watchdog shutdown on close"
  167.     depends on WATCHDOG
  168.  
  169. config SOFT_WATCHDOG
  170.     tristate "Software Watchdog"
  171.     depends on WATCHDOG
  172.  
  173. config UML_WATCHDOG
  174.     tristate "UML watchdog"
  175.     depends on WATCHDOG
  176.  
  177. config UML_SOUND
  178.     tristate "Sound support"
  179.     help
  180.         This option enables UML sound support.  If enabled, it will pull in
  181.         soundcore and the UML hostaudio relay, which acts as a intermediary
  182.         between the host's dsp and mixer devices and the UML sound system.
  183.         It is safe to say 'Y' here.
  184.  
  185. config SOUND
  186.     tristate
  187.     default UML_SOUND
  188.  
  189. config HOSTAUDIO
  190.     tristate
  191.     default UML_SOUND
  192.  
  193. config UML_RANDOM
  194.     tristate "Hardware random number generator"
  195.     help
  196.     This option enables UML's "hardware" random number generator.  It
  197.     attaches itself to the host's /dev/random, supplying as much entropy
  198.     as the host has, rather than the small amount the UML gets from its
  199.     own drivers.  It registers itself as a standard hardware random number
  200.     generator, major 10, minor 183, and the canonical device name is
  201.     /dev/hwrng.
  202.     The way to make use of this is to install the rng-tools package
  203.     (check your distro, or download from
  204.     http://sourceforge.net/projects/gkernel/).  rngd periodically reads
  205.     /dev/hwrng and injects the entropy into /dev/random.
  206.  
  207. config MMAPPER
  208.     tristate "iomem emulation driver"
  209.     help
  210.     This driver allows a host file to be used as emulated IO memory inside
  211.     UML.
  212.  
  213. endmenu
  214.  
  215.