xref: /openbmc/linux/arch/um/drivers/Kconfig (revision c900529f3d9161bfde5cca0754f83b4d3c3e0220)
1 # SPDX-License-Identifier: GPL-2.0
2 
3 menu "UML Character Devices"
4 
5 config STDERR_CONSOLE
6 	bool "stderr console"
7 	default y
8 	help
9 	  console driver which dumps all printk messages to stderr.
10 
11 config SSL
12 	bool "Virtual serial line"
13 	help
14 	  The User-Mode Linux environment allows you to create virtual serial
15 	  lines on the UML that are usually made to show up on the host as
16 	  ttys or ptys.
17 
18 	  See <http://user-mode-linux.sourceforge.net/old/input.html> for more
19 	  information and command line examples of how to use this facility.
20 
21 	  Unless you have a specific reason for disabling this, say Y.
22 
23 config NULL_CHAN
24 	bool "null channel support"
25 	help
26 	  This option enables support for attaching UML consoles and serial
27 	  lines to a device similar to /dev/null.  Data written to it disappears
28 	  and there is never any data to be read.
29 
30 config PORT_CHAN
31 	bool "port channel support"
32 	help
33 	  This option enables support for attaching UML consoles and serial
34 	  lines to host portals.  They may be accessed with 'telnet <host>
35 	  <port number>'.  Any number of consoles and serial lines may be
36 	  attached to a single portal, although what UML device you get when
37 	  you telnet to that portal will be unpredictable.
38 	  It is safe to say 'Y' here.
39 
40 config PTY_CHAN
41 	bool "pty channel support"
42 	help
43 	  This option enables support for attaching UML consoles and serial
44 	  lines to host pseudo-terminals.  Access to both traditional
45 	  pseudo-terminals (/dev/pty*) and pts pseudo-terminals are controlled
46 	  with this option.  The assignment of UML devices to host devices
47 	  will be announced in the kernel message log.
48 	  It is safe to say 'Y' here.
49 
50 config TTY_CHAN
51 	bool "tty channel support"
52 	help
53 	  This option enables support for attaching UML consoles and serial
54 	  lines to host terminals.  Access to both virtual consoles
55 	  (/dev/tty*) and the slave side of pseudo-terminals (/dev/ttyp* and
56 	  /dev/pts/*) are controlled by this option.
57 	  It is safe to say 'Y' here.
58 
59 config XTERM_CHAN
60 	bool "xterm channel support"
61 	help
62 	  This option enables support for attaching UML consoles and serial
63 	  lines to xterms.  Each UML device so assigned will be brought up in
64 	  its own xterm.
65 	  It is safe to say 'Y' here.
66 
67 config XTERM_CHAN_DEFAULT_EMULATOR
68 	string "xterm channel default terminal emulator"
69 	depends on XTERM_CHAN
70 	default "xterm"
71 	help
72 	  This option allows changing the default terminal emulator.
73 
74 config NOCONFIG_CHAN
75 	bool
76 	default !(XTERM_CHAN && TTY_CHAN && PTY_CHAN && PORT_CHAN && NULL_CHAN)
77 
78 config CON_ZERO_CHAN
79 	string "Default main console channel initialization"
80 	default "fd:0,fd:1"
81 	help
82 	  This is the string describing the channel to which the main console
83 	  will be attached by default.  This value can be overridden from the
84 	  command line.  The default value is "fd:0,fd:1", which attaches the
85 	  main console to stdin and stdout.
86 	  It is safe to leave this unchanged.
87 
88 config CON_CHAN
89 	string "Default console channel initialization"
90 	default "xterm"
91 	help
92 	  This is the string describing the channel to which all consoles
93 	  except the main console will be attached by default.  This value can
94 	  be overridden from the command line.  The default value is "xterm",
95 	  which brings them up in xterms.
96 	  It is safe to leave this unchanged, although you may wish to change
97 	  this if you expect the UML that you build to be run in environments
98 	  which don't have X or xterm available.
99 
100 config SSL_CHAN
101 	string "Default serial line channel initialization"
102 	default "pty"
103 	help
104 	  This is the string describing the channel to which the serial lines
105 	  will be attached by default.  This value can be overridden from the
106 	  command line.  The default value is "pty", which attaches them to
107 	  traditional pseudo-terminals.
108 	  It is safe to leave this unchanged, although you may wish to change
109 	  this if you expect the UML that you build to be run in environments
110 	  which don't have a set of /dev/pty* devices.
111 
112 config UML_SOUND
113 	tristate "Sound support"
114 	depends on SOUND
115 	select SOUND_OSS_CORE
116 	help
117 	  This option enables UML sound support.  If enabled, it will pull in
118 	  the UML hostaudio relay, which acts as a intermediary
119 	  between the host's dsp and mixer devices and the UML sound system.
120 	  It is safe to say 'Y' here.
121 
122 endmenu
123 
124 menu "UML Network Devices"
125 	depends on NET
126 
127 # UML virtual driver
128 config UML_NET
129 	bool "Virtual network device"
130 	help
131 	  While the User-Mode port cannot directly talk to any physical
132 	  hardware devices, this choice and the following transport options
133 	  provide one or more virtual network devices through which the UML
134 	  kernels can talk to each other, the host, and with the host's help,
135 	  machines on the outside world.
136 
137 	  For more information, including explanations of the networking and
138 	  sample configurations, see
139 	  <http://user-mode-linux.sourceforge.net/old/networking.html>.
140 
141 	  If you'd like to be able to enable networking in the User-Mode
142 	  linux environment, say Y; otherwise say N.  Note that you must
143 	  enable at least one of the following transport options to actually
144 	  make use of UML networking.
145 
146 config UML_NET_ETHERTAP
147 	bool "Ethertap transport (obsolete)"
148 	depends on UML_NET
149 	help
150 	  The Ethertap User-Mode Linux network transport allows a single
151 	  running UML to exchange packets with its host over one of the
152 	  host's Ethertap devices, such as /dev/tap0.  Additional running
153 	  UMLs can use additional Ethertap devices, one per running UML.
154 	  While the UML believes it's on a (multi-device, broadcast) virtual
155 	  Ethernet network, it's in fact communicating over a point-to-point
156 	  link with the host.
157 
158 	  To use this, your host kernel must have support for Ethertap
159 	  devices.  Also, if your host kernel is 2.4.x, it must have
160 	  CONFIG_NETLINK_DEV configured as Y or M.
161 
162 	  For more information, see
163 	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site
164 	  has examples of the UML command line to use to enable Ethertap
165 	  networking.
166 
167 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
168 	  migrate to UML_NET_VECTOR.
169 
170 	  If unsure, say N.
171 
172 config UML_NET_TUNTAP
173 	bool "TUN/TAP transport (obsolete)"
174 	depends on UML_NET
175 	help
176 	  The UML TUN/TAP network transport allows a UML instance to exchange
177 	  packets with the host over a TUN/TAP device.  This option will only
178 	  work with a 2.4 host, unless you've applied the TUN/TAP patch to
179 	  your 2.2 host kernel.
180 
181 	  To use this transport, your host kernel must have support for TUN/TAP
182 	  devices, either built-in or as a module.
183 
184 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
185 	  migrate to UML_NET_VECTOR.
186 
187 	  If unsure, say N.
188 
189 config UML_NET_SLIP
190 	bool "SLIP transport (obsolete)"
191 	depends on UML_NET
192 	help
193 	  The slip User-Mode Linux network transport allows a running UML to
194 	  network with its host over a point-to-point link.  Unlike Ethertap,
195 	  which can carry any Ethernet frame (and hence even non-IP packets),
196 	  the slip transport can only carry IP packets.
197 
198 	  To use this, your host must support slip devices.
199 
200 	  For more information, see
201 	  <http://user-mode-linux.sourceforge.net/old/networking.html>.
202 	  has examples of the UML command line to use to enable slip
203 	  networking, and details of a few quirks with it.
204 
205 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
206 	  migrate to UML_NET_VECTOR.
207 
208 	  If unsure, say N.
209 
210 config UML_NET_DAEMON
211 	bool "Daemon transport (obsolete)"
212 	depends on UML_NET
213 	help
214 	  This User-Mode Linux network transport allows one or more running
215 	  UMLs on a single host to communicate with each other, but not to
216 	  the host.
217 
218 	  To use this form of networking, you'll need to run the UML
219 	  networking daemon on the host.
220 
221 	  For more information, see
222 	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site
223 	  has examples of the UML command line to use to enable Daemon
224 	  networking.
225 
226 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
227 	  migrate to UML_NET_VECTOR.
228 
229 	  If unsure, say N.
230 
231 config UML_NET_DAEMON_DEFAULT_SOCK
232 	string "Default socket for daemon transport"
233 	default "/tmp/uml.ctl"
234 	depends on UML_NET_DAEMON
235 	help
236 	  This option allows setting the default socket for the daemon
237 	  transport, normally it defaults to /tmp/uml.ctl.
238 
239 config UML_NET_VECTOR
240 	bool "Vector I/O high performance network devices"
241 	depends on UML_NET
242 	select MAY_HAVE_RUNTIME_DEPS
243 	help
244 	  This User-Mode Linux network driver uses multi-message send
245 	  and receive functions. The host running the UML guest must have
246 	  a linux kernel version above 3.0 and a libc version > 2.13.
247 	  This driver provides tap, raw, gre and l2tpv3 network transports
248 	  with up to 4 times higher network throughput than the UML network
249 	  drivers.
250 
251 config UML_NET_VDE
252 	bool "VDE transport (obsolete)"
253 	depends on UML_NET
254 	depends on !MODVERSIONS
255 	select MAY_HAVE_RUNTIME_DEPS
256 	help
257 	  This User-Mode Linux network transport allows one or more running
258 	  UMLs on a single host to communicate with each other and also
259 	  with the rest of the world using Virtual Distributed Ethernet,
260 	  an improved fork of uml_switch.
261 
262 	  You must have libvdeplug installed in order to build the vde
263 	  transport into UML.
264 
265 	  To use this form of networking, you will need to run vde_switch
266 	  on the host.
267 
268 	  For more information, see <http://wiki.virtualsquare.org/>
269 	  That site has a good overview of what VDE is and also examples
270 	  of the UML command line to use to enable VDE networking.
271 
272 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
273 	  migrate to UML_NET_VECTOR.
274 
275 	  If unsure, say N.
276 
277 config UML_NET_MCAST
278 	bool "Multicast transport (obsolete)"
279 	depends on UML_NET
280 	help
281 	  This Multicast User-Mode Linux network transport allows multiple
282 	  UMLs (even ones running on different host machines!) to talk to
283 	  each other over a virtual ethernet network.  However, it requires
284 	  at least one UML with one of the other transports to act as a
285 	  bridge if any of them need to be able to talk to their hosts or any
286 	  other IP machines.
287 
288 	  To use this, your host kernel(s) must support IP Multicasting.
289 
290 	  For more information, see
291 	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site
292 	  has examples of the UML command line to use to enable Multicast
293 	  networking, and notes about the security of this approach.
294 
295 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
296 	  migrate to UML_NET_VECTOR.
297 
298 	  If unsure, say N.
299 
300 config UML_NET_PCAP
301 	bool "pcap transport (obsolete)"
302 	depends on UML_NET
303 	depends on !MODVERSIONS
304 	select MAY_HAVE_RUNTIME_DEPS
305 	help
306 	  The pcap transport makes a pcap packet stream on the host look
307 	  like an ethernet device inside UML.  This is useful for making
308 	  UML act as a network monitor for the host.  You must have libcap
309 	  installed in order to build the pcap transport into UML.
310 
311 	  For more information, see
312 	  <http://user-mode-linux.sourceforge.net/old/networking.html>  That site
313 	  has examples of the UML command line to use to enable this option.
314 
315 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
316 	  migrate to UML_NET_VECTOR.
317 
318 	  If unsure, say N.
319 
320 config UML_NET_SLIRP
321 	bool "SLiRP transport (obsolete)"
322 	depends on UML_NET
323 	help
324 	  The SLiRP User-Mode Linux network transport allows a running UML
325 	  to network by invoking a program that can handle SLIP encapsulated
326 	  packets.  This is commonly (but not limited to) the application
327 	  known as SLiRP, a program that can re-socket IP packets back onto
328 	  he host on which it is run.  Only IP packets are supported,
329 	  unlike other network transports that can handle all Ethernet
330 	  frames.  In general, slirp allows the UML the same IP connectivity
331 	  to the outside world that the host user is permitted, and unlike
332 	  other transports, SLiRP works without the need of root level
333 	  privileges, setuid binaries, or SLIP devices on the host.  This
334 	  also means not every type of connection is possible, but most
335 	  situations can be accommodated with carefully crafted slirp
336 	  commands that can be passed along as part of the network device's
337 	  setup string.  The effect of this transport on the UML is similar
338 	  that of a host behind a firewall that masquerades all network
339 	  connections passing through it (but is less secure).
340 
341 	  NOTE: THIS TRANSPORT IS DEPRECATED AND WILL BE REMOVED SOON!!! Please
342 	  migrate to UML_NET_VECTOR.
343 
344 	  If unsure, say N.
345 
346 	  Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp"
347 
348 endmenu
349 
350 config VIRTIO_UML
351 	bool "UML driver for virtio devices"
352 	select VIRTIO
353 	help
354 	  This driver provides support for virtio based paravirtual device
355 	  drivers over vhost-user sockets.
356 
357 config UML_RTC
358 	bool "UML RTC driver"
359 	depends on RTC_CLASS
360 	# there's no use in this if PM_SLEEP isn't enabled ...
361 	depends on PM_SLEEP
362 	help
363 	  When PM_SLEEP is configured, it may be desirable to wake up using
364 	  rtcwake, especially in time-travel mode. This driver enables that
365 	  by providing a fake RTC clock that causes a wakeup at the right
366 	  time.
367 
368 config UML_PCI_OVER_VIRTIO
369 	bool "Enable PCI over VIRTIO device simulation"
370 	# in theory, just VIRTIO is enough, but that causes recursion
371 	depends on VIRTIO_UML
372 	select FORCE_PCI
373 	select UML_IOMEM_EMULATION
374 	select UML_DMA_EMULATION
375 	select PCI_MSI
376 	select PCI_LOCKLESS_CONFIG
377 
378 config UML_PCI_OVER_VIRTIO_DEVICE_ID
379 	int "set the virtio device ID for PCI emulation"
380 	default -1
381 	depends on UML_PCI_OVER_VIRTIO
382 	help
383 	  There's no official device ID assigned (yet), set the one you
384 	  wish to use for experimentation here. The default of -1 is
385 	  not valid and will cause the driver to fail at probe.
386