| config TTY |
| bool "Enable TTY" if EXPERT |
| default y |
| ---help--- |
| Allows you to remove TTY support which can save space, and |
| blocks features that require TTY from inclusion in the kernel. |
| TTY is required for any text terminals or serial port |
| communication. Most users should leave this enabled. |
| |
| if TTY |
| |
| config VT |
| bool "Virtual terminal" if EXPERT |
| depends on !S390 && !UML |
| select INPUT |
| default y |
| ---help--- |
| If you say Y here, you will get support for terminal devices with |
| display and keyboard devices. These are called "virtual" because you |
| can run several virtual terminals (also called virtual consoles) on |
| one physical terminal. This is rather useful, for example one |
| virtual terminal can collect system messages and warnings, another |
| one can be used for a text-mode user session, and a third could run |
| an X session, all in parallel. Switching between virtual terminals |
| is done with certain key combinations, usually Alt-<function key>. |
| |
| The setterm command ("man setterm") can be used to change the |
| properties (such as colors or beeping) of a virtual terminal. The |
| man page console_codes(4) ("man console_codes") contains the special |
| character sequences that can be used to change those properties |
| directly. The fonts used on virtual terminals can be changed with |
| the setfont ("man setfont") command and the key bindings are defined |
| with the loadkeys ("man loadkeys") command. |
| |
| You need at least one virtual terminal device in order to make use |
| of your keyboard and monitor. Therefore, only people configuring an |
| embedded system would want to say N here in order to save some |
| memory; the only way to log into such a system is then via a serial |
| or network connection. |
| |
| If unsure, say Y, or else you won't be able to do much with your new |
| shiny Linux system :-) |
| |
| config CONSOLE_TRANSLATIONS |
| depends on VT |
| default y |
| bool "Enable character translations in console" if EXPERT |
| ---help--- |
| This enables support for font mapping and Unicode translation |
| on virtual consoles. |
| |
| config VT_CONSOLE |
| bool "Support for console on virtual terminal" if EXPERT |
| depends on VT |
| default y |
| ---help--- |
| The system console is the device which receives all kernel messages |
| and warnings and which allows logins in single user mode. If you |
| answer Y here, a virtual terminal (the device used to interact with |
| a physical terminal) can be used as system console. This is the most |
| common mode of operations, so you should say Y here unless you want |
| the kernel messages be output only to a serial port (in which case |
| you should say Y to "Console on serial port", below). |
| |
| If you do say Y here, by default the currently visible virtual |
| terminal (/dev/tty0) will be used as system console. You can change |
| that with a kernel command line option such as "console=tty3" which |
| would use the third virtual terminal as system console. (Try "man |
| bootparam" or see the documentation of your boot loader (lilo or |
| loadlin) about how to pass options to the kernel at boot time.) |
| |
| If unsure, say Y. |
| |
| config VT_CONSOLE_SLEEP |
| def_bool y |
| depends on VT_CONSOLE && PM_SLEEP |
| |
| config HW_CONSOLE |
| bool |
| depends on VT && !UML |
| default y |
| |
| config VT_HW_CONSOLE_BINDING |
| bool "Support for binding and unbinding console drivers" |
| depends on HW_CONSOLE |
| default n |
| ---help--- |
| The virtual terminal is the device that interacts with the physical |
| terminal through console drivers. On these systems, at least one |
| console driver is loaded. In other configurations, additional console |
| drivers may be enabled, such as the framebuffer console. If more than |
| 1 console driver is enabled, setting this to 'y' will allow you to |
| select the console driver that will serve as the backend for the |
| virtual terminals. |
| |
| See <file:Documentation/console/console.txt> for more |
| information. For framebuffer console users, please refer to |
| <file:Documentation/fb/fbcon.txt>. |
| |
| config UNIX98_PTYS |
| bool "Unix98 PTY support" if EXPERT |
| 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. 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 DEVPTS_MULTIPLE_INSTANCES |
| bool "Support multiple instances of devpts" |
| depends on UNIX98_PTYS |
| default n |
| ---help--- |
| Enable support for multiple instances of devpts filesystem. |
| If you want to have isolated PTY namespaces (eg: in containers), |
| say Y here. Otherwise, say N. If enabled, each mount of devpts |
| filesystem with the '-o newinstance' option will create an |
| independent PTY namespace. |
| |
| 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 |
| range 0 256 |
| 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 BFIN_JTAG_COMM |
| tristate "Blackfin JTAG Communication" |
| depends on BLACKFIN |
| help |
| Add support for emulating a TTY device over the Blackfin JTAG. |
| |
| To compile this driver as a module, choose M here: the |
| module will be called bfin_jtag_comm. |
| |
| config BFIN_JTAG_COMM_CONSOLE |
| bool "Console on Blackfin JTAG" |
| depends on BFIN_JTAG_COMM=y |
| |
| config SERIAL_NONSTANDARD |
| bool "Non-standard serial port support" |
| depends on HAS_IOMEM |
| ---help--- |
| Say Y here if you have any non-standard serial boards -- boards |
| which aren't supported using the standard "dumb" serial driver. |
| This includes intelligent serial boards such as Cyclades, |
| Digiboards, etc. These are usually used for systems that need many |
| serial ports because they serve many terminals or dial-in |
| connections. |
| |
| Note that the answer to this question won't directly affect the |
| kernel: saying N will just cause the configurator to skip all |
| the questions about non-standard serial boards. |
| |
| Most people can say N here. |
| |
| config ROCKETPORT |
| tristate "Comtrol RocketPort support" |
| depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) |
| help |
| This driver supports Comtrol RocketPort and RocketModem PCI boards. |
| These boards provide 2, 4, 8, 16, or 32 high-speed serial ports or |
| modems. For information about the RocketPort/RocketModem boards |
| and this driver read <file:Documentation/serial/rocket.txt>. |
| |
| To compile this driver as a module, choose M here: the |
| module will be called rocket. |
| |
| If you want to compile this driver into the kernel, say Y here. If |
| you don't have a Comtrol RocketPort/RocketModem card installed, say N. |
| |
| config CYCLADES |
| tristate "Cyclades async mux support" |
| depends on SERIAL_NONSTANDARD && (PCI || ISA) |
| select FW_LOADER |
| ---help--- |
| This driver supports Cyclades Z and Y multiserial boards. |
| You would need something like this to connect more than two modems to |
| your Linux box, for instance in order to become a dial-in server. |
| |
| For information about the Cyclades-Z card, read |
| <file:Documentation/serial/README.cycladesZ>. |
| |
| To compile this driver as a module, choose M here: the |
| module will be called cyclades. |
| |
| If you haven't heard about it, it's safe to say N. |
| |
| config CYZ_INTR |
| bool "Cyclades-Z interrupt mode operation" |
| depends on CYCLADES |
| help |
| The Cyclades-Z family of multiport cards allows 2 (two) driver op |
| modes: polling and interrupt. In polling mode, the driver will check |
| the status of the Cyclades-Z ports every certain amount of time |
| (which is called polling cycle and is configurable). In interrupt |
| mode, it will use an interrupt line (IRQ) in order to check the |
| status of the Cyclades-Z ports. The default op mode is polling. If |
| unsure, say N. |
| |
| config MOXA_INTELLIO |
| tristate "Moxa Intellio support" |
| depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) |
| select FW_LOADER |
| help |
| Say Y here if you have a Moxa Intellio multiport serial card. |
| |
| To compile this driver as a module, choose M here: the |
| module will be called moxa. |
| |
| config MOXA_SMARTIO |
| tristate "Moxa SmartIO support v. 2.0" |
| depends on SERIAL_NONSTANDARD && (PCI || EISA || ISA) |
| help |
| Say Y here if you have a Moxa SmartIO multiport serial card and/or |
| want to help develop a new version of this driver. |
| |
| This is upgraded (1.9.1) driver from original Moxa drivers with |
| changes finally resulting in PCI probing. |
| |
| This driver can also be built as a module. The module will be called |
| mxser. If you want to do that, say M here. |
| |
| config SYNCLINK |
| tristate "Microgate SyncLink card support" |
| depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API |
| help |
| Provides support for the SyncLink ISA and PCI multiprotocol serial |
| adapters. These adapters support asynchronous and HDLC bit |
| synchronous communication up to 10Mbps (PCI adapter). |
| |
| This driver can only be built as a module ( = code which can be |
| inserted in and removed from the running kernel whenever you want). |
| The module will be called synclink. If you want to do that, say M |
| here. |
| |
| config SYNCLINKMP |
| tristate "SyncLink Multiport support" |
| depends on SERIAL_NONSTANDARD && PCI |
| help |
| Enable support for the SyncLink Multiport (2 or 4 ports) |
| serial adapter, running asynchronous and HDLC communications up |
| to 2.048Mbps. Each ports is independently selectable for |
| RS-232, V.35, RS-449, RS-530, and X.21 |
| |
| This driver may be built as a module ( = code which can be |
| inserted in and removed from the running kernel whenever you want). |
| The module will be called synclinkmp. If you want to do that, say M |
| here. |
| |
| config SYNCLINK_GT |
| tristate "SyncLink GT/AC support" |
| depends on SERIAL_NONSTANDARD && PCI |
| help |
| Support for SyncLink GT and SyncLink AC families of |
| synchronous and asynchronous serial adapters |
| manufactured by Microgate Systems, Ltd. (www.microgate.com) |
| |
| config NOZOMI |
| tristate "HSDPA Broadband Wireless Data Card - Globe Trotter" |
| depends on PCI |
| help |
| If you have a HSDPA driver Broadband Wireless Data Card - |
| Globe Trotter PCMCIA card, say Y here. |
| |
| To compile this driver as a module, choose M here, the module |
| will be called nozomi. |
| |
| config ISI |
| tristate "Multi-Tech multiport card support" |
| depends on SERIAL_NONSTANDARD && PCI |
| select FW_LOADER |
| help |
| This is a driver for the Multi-Tech cards which provide several |
| serial ports. The driver is experimental and can currently only be |
| built as a module. The module will be called isicom. |
| If you want to do that, choose M here. |
| |
| config N_HDLC |
| tristate "HDLC line discipline support" |
| depends on SERIAL_NONSTANDARD |
| help |
| Allows synchronous HDLC communications with tty device drivers that |
| support synchronous HDLC such as the Microgate SyncLink adapter. |
| |
| This driver can be built as a module ( = code which can be |
| inserted in and removed from the running kernel whenever you want). |
| The module will be called n_hdlc. If you want to do that, say M |
| here. |
| |
| config N_GSM |
| tristate "GSM MUX line discipline support (EXPERIMENTAL)" |
| depends on NET |
| help |
| This line discipline provides support for the GSM MUX protocol and |
| presents the mux as a set of 61 individual tty devices. |
| |
| config N_SMUX |
| tristate "SMUX line discipline support" |
| depends on NET && SERIAL_MSM_HS |
| help |
| This line discipline provides support for the Serial MUX protocol |
| and provides a TTY and kernel API for multiple logical channels. |
| |
| config N_SMUX_LOOPBACK |
| tristate "SMUX line discipline loopback support" |
| depends on N_SMUX |
| help |
| Provides loopback and unit testing support for the Serial MUX Protocol. |
| |
| config SMUX_CTL |
| tristate "SMUX control driver" |
| depends on N_SMUX |
| help |
| Support for SMUX control driver on top of serial MUX. |
| |
| config TRACE_ROUTER |
| tristate "Trace data router for MIPI P1149.7 cJTAG standard" |
| depends on TRACE_SINK |
| default n |
| help |
| The trace router uses the Linux tty line discipline framework to |
| route trace data coming from a tty port (say UART for example) to |
| the trace sink line discipline driver and to another tty port (say |
| USB). This is part of a solution for the MIPI P1149.7, compact JTAG, |
| standard, which is for debugging mobile devices. The PTI driver in |
| drivers/misc/pti.c defines the majority of this MIPI solution. |
| |
| You should select this driver if the target kernel is meant for |
| a mobile device containing a modem. Then you will need to select |
| "Trace data sink for MIPI P1149.7 cJTAG standard" line discipline |
| driver. |
| |
| config TRACE_SINK |
| tristate "Trace data sink for MIPI P1149.7 cJTAG standard" |
| default n |
| help |
| The trace sink uses the Linux line discipline framework to receive |
| trace data coming from the trace router line discipline driver |
| to a user-defined tty port target, like USB. |
| This is to provide a way to extract modem trace data on |
| devices that do not have a PTI HW module, or just need modem |
| trace data to come out of a different HW output port. |
| This is part of a solution for the P1149.7, compact JTAG, standard. |
| |
| If you select this option, you need to select |
| "Trace data router for MIPI P1149.7 cJTAG standard". |
| |
| config PPC_EPAPR_HV_BYTECHAN |
| tristate "ePAPR hypervisor byte channel driver" |
| depends on PPC |
| select EPAPR_PARAVIRT |
| help |
| This driver creates /dev entries for each ePAPR hypervisor byte |
| channel, thereby allowing applications to communicate with byte |
| channels as if they were serial ports. |
| |
| config PPC_EARLY_DEBUG_EHV_BC |
| bool "Early console (udbg) support for ePAPR hypervisors" |
| depends on PPC_EPAPR_HV_BYTECHAN=y |
| help |
| Select this option to enable early console (a.k.a. "udbg") support |
| via an ePAPR byte channel. You also need to choose the byte channel |
| handle below. |
| |
| config PPC_EARLY_DEBUG_EHV_BC_HANDLE |
| int "Byte channel handle for early console (udbg)" |
| depends on PPC_EARLY_DEBUG_EHV_BC |
| default 0 |
| help |
| If you want early console (udbg) output through a byte channel, |
| specify the handle of the byte channel to use. |
| |
| For this to work, the byte channel driver must be compiled |
| in-kernel, not as a module. |
| |
| Note that only one early console driver can be enabled, so don't |
| enable any others if you enable this one. |
| |
| If the number you specify is not a valid byte channel handle, then |
| there simply will be no early console output. This is true also |
| if you don't boot under a hypervisor at all. |
| |
| config GOLDFISH_TTY |
| tristate "Goldfish TTY Driver" |
| depends on GOLDFISH |
| help |
| Console and system TTY driver for the Goldfish virtual platform. |
| |
| config DA_TTY |
| bool "DA TTY" |
| depends on METAG_DA |
| select SERIAL_NONSTANDARD |
| help |
| This enables a TTY on a Dash channel. |
| |
| config DA_CONSOLE |
| bool "DA Console" |
| depends on DA_TTY |
| help |
| This enables a console on a Dash channel. |
| |
| endif # TTY |