Root/
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/old/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 | It is safe to say 'Y' here. |
69 | |
70 | config NOCONFIG_CHAN |
71 | bool |
72 | default !(XTERM_CHAN && TTY_CHAN && PTY_CHAN && PORT_CHAN && NULL_CHAN) |
73 | |
74 | config CON_ZERO_CHAN |
75 | string "Default main console channel initialization" |
76 | default "fd:0,fd:1" |
77 | help |
78 | This is the string describing the channel to which the main console |
79 | will be attached by default. This value can be overridden from the |
80 | command line. The default value is "fd:0,fd:1", which attaches the |
81 | main console to stdin and stdout. |
82 | It is safe to leave this unchanged. |
83 | |
84 | config CON_CHAN |
85 | string "Default console channel initialization" |
86 | default "xterm" |
87 | help |
88 | This is the string describing the channel to which all consoles |
89 | except the main console will be attached by default. This value can |
90 | be overridden from the command line. The default value is "xterm", |
91 | which brings them up in xterms. |
92 | It is safe to leave this unchanged, although you may wish to change |
93 | this if you expect the UML that you build to be run in environments |
94 | which don't have X or xterm available. |
95 | |
96 | config SSL_CHAN |
97 | string "Default serial line channel initialization" |
98 | default "pty" |
99 | help |
100 | This is the string describing the channel to which the serial lines |
101 | will be attached by default. This value can be overridden from the |
102 | command line. The default value is "pty", which attaches them to |
103 | traditional pseudo-terminals. |
104 | It is safe to leave this unchanged, although you may wish to change |
105 | this if you expect the UML that you build to be run in environments |
106 | which don't have a set of /dev/pty* devices. |
107 | |
108 | config UNIX98_PTYS |
109 | bool "Unix98 PTY support" |
110 | help |
111 | A pseudo terminal (PTY) is a software device consisting of two |
112 | halves: a master and a slave. The slave device behaves identical to |
113 | a physical terminal; the master device is used by a process to |
114 | read data from and write data to the slave, thereby emulating a |
115 | terminal. Typical programs for the master side are telnet servers |
116 | and xterms. |
117 | |
118 | Linux has traditionally used the BSD-like names /dev/ptyxx for |
119 | masters and /dev/ttyxx for slaves of pseudo terminals. This scheme |
120 | has a number of problems. The GNU C library glibc 2.1 and later, |
121 | however, supports the Unix98 naming standard: in order to acquire a |
122 | pseudo terminal, a process opens /dev/ptmx; the number of the pseudo |
123 | terminal is then made available to the process and the pseudo |
124 | terminal slave can be accessed as /dev/pts/<number>. What was |
125 | traditionally /dev/ttyp2 will then be /dev/pts/2, for example. |
126 | |
127 | All modern Linux systems use the Unix98 ptys. Say Y unless |
128 | you're on an embedded system and want to conserve memory. |
129 | |
130 | config LEGACY_PTYS |
131 | bool "Legacy (BSD) PTY support" |
132 | default y |
133 | help |
134 | A pseudo terminal (PTY) is a software device consisting of two |
135 | halves: a master and a slave. The slave device behaves identical to |
136 | a physical terminal; the master device is used by a process to |
137 | read data from and write data to the slave, thereby emulating a |
138 | terminal. Typical programs for the master side are telnet servers |
139 | and xterms. |
140 | |
141 | Linux has traditionally used the BSD-like names /dev/ptyxx |
142 | for masters and /dev/ttyxx for slaves of pseudo |
143 | terminals. This scheme has a number of problems, including |
144 | security. This option enables these legacy devices; on most |
145 | systems, it is safe to say N. |
146 | |
147 | config RAW_DRIVER |
148 | tristate "RAW driver (/dev/raw/rawN)" |
149 | depends on BLOCK |
150 | help |
151 | The raw driver permits block devices to be bound to /dev/raw/rawN. |
152 | Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O. |
153 | See the raw(8) manpage for more details. |
154 | |
155 | Applications should preferably open the device (eg /dev/hda1) |
156 | with the O_DIRECT flag. |
157 | |
158 | config MAX_RAW_DEVS |
159 | int "Maximum number of RAW devices to support (1-8192)" |
160 | depends on RAW_DRIVER |
161 | default "256" |
162 | help |
163 | The maximum number of RAW devices that are supported. |
164 | Default is 256. Increase this number in case you need lots of |
165 | raw devices. |
166 | |
167 | config LEGACY_PTY_COUNT |
168 | int "Maximum number of legacy PTY in use" |
169 | depends on LEGACY_PTYS |
170 | default "256" |
171 | help |
172 | The maximum number of legacy PTYs that can be used at any one time. |
173 | The default is 256, and should be more than enough. Embedded |
174 | systems may want to reduce this to save memory. |
175 | |
176 | When not in use, each legacy PTY occupies 12 bytes on 32-bit |
177 | architectures and 24 bytes on 64-bit architectures. |
178 | |
179 | config WATCHDOG |
180 | bool "Watchdog Timer Support" |
181 | |
182 | config WATCHDOG_NOWAYOUT |
183 | bool "Disable watchdog shutdown on close" |
184 | depends on WATCHDOG |
185 | |
186 | config SOFT_WATCHDOG |
187 | tristate "Software Watchdog" |
188 | depends on WATCHDOG |
189 | |
190 | config UML_WATCHDOG |
191 | tristate "UML watchdog" |
192 | depends on WATCHDOG |
193 | |
194 | config UML_SOUND |
195 | tristate "Sound support" |
196 | help |
197 | This option enables UML sound support. If enabled, it will pull in |
198 | soundcore and the UML hostaudio relay, which acts as a intermediary |
199 | between the host's dsp and mixer devices and the UML sound system. |
200 | It is safe to say 'Y' here. |
201 | |
202 | config SOUND |
203 | tristate |
204 | default UML_SOUND |
205 | |
206 | config SOUND_OSS_CORE |
207 | bool |
208 | default UML_SOUND |
209 | |
210 | config HOSTAUDIO |
211 | tristate |
212 | default UML_SOUND |
213 | |
214 | #It is selected elsewhere, so kconfig would warn without this. |
215 | config HW_RANDOM |
216 | tristate |
217 | default n |
218 | |
219 | config UML_RANDOM |
220 | tristate "Hardware random number generator" |
221 | help |
222 | This option enables UML's "hardware" random number generator. It |
223 | attaches itself to the host's /dev/random, supplying as much entropy |
224 | as the host has, rather than the small amount the UML gets from its |
225 | own drivers. It registers itself as a standard hardware random number |
226 | generator, major 10, minor 183, and the canonical device name is |
227 | /dev/hwrng. |
228 | The way to make use of this is to install the rng-tools package |
229 | (check your distro, or download from |
230 | http://sourceforge.net/projects/gkernel/). rngd periodically reads |
231 | /dev/hwrng and injects the entropy into /dev/random. |
232 | |
233 | config MMAPPER |
234 | tristate "iomem emulation driver" |
235 | help |
236 | This driver allows a host file to be used as emulated IO memory inside |
237 | UML. |
238 | |
239 | endmenu |
240 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9