diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /arch/um/Kconfig_net |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'arch/um/Kconfig_net')
-rw-r--r-- | arch/um/Kconfig_net | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/arch/um/Kconfig_net b/arch/um/Kconfig_net new file mode 100644 index 000000000000..1c2f9a70d91d --- /dev/null +++ b/arch/um/Kconfig_net | |||
@@ -0,0 +1,180 @@ | |||
1 | |||
2 | menu "UML Network Devices" | ||
3 | depends on NET | ||
4 | |||
5 | # UML virtual driver | ||
6 | config UML_NET | ||
7 | bool "Virtual network device" | ||
8 | help | ||
9 | While the User-Mode port cannot directly talk to any physical | ||
10 | hardware devices, this choice and the following transport options | ||
11 | provide one or more virtual network devices through which the UML | ||
12 | kernels can talk to each other, the host, and with the host's help, | ||
13 | machines on the outside world. | ||
14 | |||
15 | For more information, including explanations of the networking and | ||
16 | sample configurations, see | ||
17 | <http://user-mode-linux.sourceforge.net/networking.html>. | ||
18 | |||
19 | If you'd like to be able to enable networking in the User-Mode | ||
20 | linux environment, say Y; otherwise say N. Note that you must | ||
21 | enable at least one of the following transport options to actually | ||
22 | make use of UML networking. | ||
23 | |||
24 | config UML_NET_ETHERTAP | ||
25 | bool "Ethertap transport" | ||
26 | depends on UML_NET | ||
27 | help | ||
28 | The Ethertap User-Mode Linux network transport allows a single | ||
29 | running UML to exchange packets with its host over one of the | ||
30 | host's Ethertap devices, such as /dev/tap0. Additional running | ||
31 | UMLs can use additional Ethertap devices, one per running UML. | ||
32 | While the UML believes it's on a (multi-device, broadcast) virtual | ||
33 | Ethernet network, it's in fact communicating over a point-to-point | ||
34 | link with the host. | ||
35 | |||
36 | To use this, your host kernel must have support for Ethertap | ||
37 | devices. Also, if your host kernel is 2.4.x, it must have | ||
38 | CONFIG_NETLINK_DEV configured as Y or M. | ||
39 | |||
40 | For more information, see | ||
41 | <http://user-mode-linux.sourceforge.net/networking.html> That site | ||
42 | has examples of the UML command line to use to enable Ethertap | ||
43 | networking. | ||
44 | |||
45 | If you'd like to set up an IP network with the host and/or the | ||
46 | outside world, say Y to this, the Daemon Transport and/or the | ||
47 | Slip Transport. You'll need at least one of them, but may choose | ||
48 | more than one without conflict. If you don't need UML networking, | ||
49 | say N. | ||
50 | |||
51 | config UML_NET_TUNTAP | ||
52 | bool "TUN/TAP transport" | ||
53 | depends on UML_NET | ||
54 | help | ||
55 | The UML TUN/TAP network transport allows a UML instance to exchange | ||
56 | packets with the host over a TUN/TAP device. This option will only | ||
57 | work with a 2.4 host, unless you've applied the TUN/TAP patch to | ||
58 | your 2.2 host kernel. | ||
59 | |||
60 | To use this transport, your host kernel must have support for TUN/TAP | ||
61 | devices, either built-in or as a module. | ||
62 | |||
63 | config UML_NET_SLIP | ||
64 | bool "SLIP transport" | ||
65 | depends on UML_NET | ||
66 | help | ||
67 | The slip User-Mode Linux network transport allows a running UML to | ||
68 | network with its host over a point-to-point link. Unlike Ethertap, | ||
69 | which can carry any Ethernet frame (and hence even non-IP packets), | ||
70 | the slip transport can only carry IP packets. | ||
71 | |||
72 | To use this, your host must support slip devices. | ||
73 | |||
74 | For more information, see | ||
75 | <http://user-mode-linux.sourceforge.net/networking.html>. That site | ||
76 | has examples of the UML command line to use to enable slip | ||
77 | networking, and details of a few quirks with it. | ||
78 | |||
79 | The Ethertap Transport is preferred over slip because of its | ||
80 | limitations. If you prefer slip, however, say Y here. Otherwise | ||
81 | choose the Multicast transport (to network multiple UMLs on | ||
82 | multiple hosts), Ethertap (to network with the host and the | ||
83 | outside world), and/or the Daemon transport (to network multiple | ||
84 | UMLs on a single host). You may choose more than one without | ||
85 | conflict. If you don't need UML networking, say N. | ||
86 | |||
87 | config UML_NET_DAEMON | ||
88 | bool "Daemon transport" | ||
89 | depends on UML_NET | ||
90 | help | ||
91 | This User-Mode Linux network transport allows one or more running | ||
92 | UMLs on a single host to communicate with each other, but not to | ||
93 | the host. | ||
94 | |||
95 | To use this form of networking, you'll need to run the UML | ||
96 | networking daemon on the host. | ||
97 | |||
98 | For more information, see | ||
99 | <http://user-mode-linux.sourceforge.net/networking.html> That site | ||
100 | has examples of the UML command line to use to enable Daemon | ||
101 | networking. | ||
102 | |||
103 | If you'd like to set up a network with other UMLs on a single host, | ||
104 | say Y. If you need a network between UMLs on multiple physical | ||
105 | hosts, choose the Multicast Transport. To set up a network with | ||
106 | the host and/or other IP machines, say Y to the Ethertap or Slip | ||
107 | transports. You'll need at least one of them, but may choose | ||
108 | more than one without conflict. If you don't need UML networking, | ||
109 | say N. | ||
110 | |||
111 | config UML_NET_MCAST | ||
112 | bool "Multicast transport" | ||
113 | depends on UML_NET | ||
114 | help | ||
115 | This Multicast User-Mode Linux network transport allows multiple | ||
116 | UMLs (even ones running on different host machines!) to talk to | ||
117 | each other over a virtual ethernet network. However, it requires | ||
118 | at least one UML with one of the other transports to act as a | ||
119 | bridge if any of them need to be able to talk to their hosts or any | ||
120 | other IP machines. | ||
121 | |||
122 | To use this, your host kernel(s) must support IP Multicasting. | ||
123 | |||
124 | For more information, see | ||
125 | <http://user-mode-linux.sourceforge.net/networking.html> That site | ||
126 | has examples of the UML command line to use to enable Multicast | ||
127 | networking, and notes about the security of this approach. | ||
128 | |||
129 | If you need UMLs on multiple physical hosts to communicate as if | ||
130 | they shared an Ethernet network, say Y. If you need to communicate | ||
131 | with other IP machines, make sure you select one of the other | ||
132 | transports (possibly in addition to Multicast; they're not | ||
133 | exclusive). If you don't need to network UMLs say N to each of | ||
134 | the transports. | ||
135 | |||
136 | config UML_NET_PCAP | ||
137 | bool "pcap transport" | ||
138 | depends on UML_NET && BROKEN | ||
139 | help | ||
140 | The pcap transport makes a pcap packet stream on the host look | ||
141 | like an ethernet device inside UML. This is useful for making | ||
142 | UML act as a network monitor for the host. You must have libcap | ||
143 | installed in order to build the pcap transport into UML. | ||
144 | |||
145 | For more information, see | ||
146 | <http://user-mode-linux.sourceforge.net/networking.html> That site | ||
147 | has examples of the UML command line to use to enable this option. | ||
148 | |||
149 | If you intend to use UML as a network monitor for the host, say | ||
150 | Y here. Otherwise, say N. | ||
151 | |||
152 | config UML_NET_SLIRP | ||
153 | bool "SLiRP transport" | ||
154 | depends on UML_NET | ||
155 | help | ||
156 | The SLiRP User-Mode Linux network transport allows a running UML | ||
157 | to network by invoking a program that can handle SLIP encapsulated | ||
158 | packets. This is commonly (but not limited to) the application | ||
159 | known as SLiRP, a program that can re-socket IP packets back onto | ||
160 | the host on which it is run. Only IP packets are supported, | ||
161 | unlike other network transports that can handle all Ethernet | ||
162 | frames. In general, slirp allows the UML the same IP connectivity | ||
163 | to the outside world that the host user is permitted, and unlike | ||
164 | other transports, SLiRP works without the need of root level | ||
165 | privleges, setuid binaries, or SLIP devices on the host. This | ||
166 | also means not every type of connection is possible, but most | ||
167 | situations can be accomodated with carefully crafted slirp | ||
168 | commands that can be passed along as part of the network device's | ||
169 | setup string. The effect of this transport on the UML is similar | ||
170 | that of a host behind a firewall that masquerades all network | ||
171 | connections passing through it (but is less secure). | ||
172 | |||
173 | To use this you should first have slirp compiled somewhere | ||
174 | accessible on the host, and have read its documentation. If you | ||
175 | don't need UML networking, say N. | ||
176 | |||
177 | Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp" | ||
178 | |||
179 | endmenu | ||
180 | |||