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 |
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')
-rw-r--r-- | arch/um/Kconfig | 320 |
1 files changed, 320 insertions, 0 deletions
diff --git a/arch/um/Kconfig b/arch/um/Kconfig new file mode 100644 index 000000000000..9a23df182123 --- /dev/null +++ b/arch/um/Kconfig | |||
@@ -0,0 +1,320 @@ | |||
1 | # UML uses the generic IRQ sugsystem | ||
2 | config GENERIC_HARDIRQS | ||
3 | bool | ||
4 | default y | ||
5 | |||
6 | config UML | ||
7 | bool | ||
8 | default y | ||
9 | |||
10 | # XXX: does UM have a mmu/swap? | ||
11 | config MMU | ||
12 | bool | ||
13 | default y | ||
14 | |||
15 | mainmenu "Linux/Usermode Kernel Configuration" | ||
16 | |||
17 | config ISA | ||
18 | bool | ||
19 | |||
20 | config SBUS | ||
21 | bool | ||
22 | |||
23 | config PCI | ||
24 | bool | ||
25 | |||
26 | config UID16 | ||
27 | bool | ||
28 | default y | ||
29 | |||
30 | config RWSEM_GENERIC_SPINLOCK | ||
31 | bool | ||
32 | default y | ||
33 | |||
34 | config GENERIC_CALIBRATE_DELAY | ||
35 | bool | ||
36 | default y | ||
37 | |||
38 | menu "UML-specific options" | ||
39 | |||
40 | config MODE_TT | ||
41 | bool "Tracing thread support" | ||
42 | default y | ||
43 | help | ||
44 | This option controls whether tracing thread support is compiled | ||
45 | into UML. Normally, this should be set to Y. If you intend to | ||
46 | use only skas mode (and the host has the skas patch applied to it), | ||
47 | then it is OK to say N here. | ||
48 | |||
49 | config STATIC_LINK | ||
50 | bool "Force a static link" | ||
51 | default n | ||
52 | depends on !MODE_TT | ||
53 | help | ||
54 | If CONFIG_MODE_TT is disabled, then this option gives you the ability | ||
55 | to force a static link of UML. Normally, if only skas mode is built | ||
56 | in to UML, it will be linked as a shared binary. This is inconvenient | ||
57 | for use in a chroot jail. So, if you intend to run UML inside a | ||
58 | chroot, and you disable CONFIG_MODE_TT, you probably want to say Y | ||
59 | here. | ||
60 | |||
61 | config MODE_SKAS | ||
62 | bool "Separate Kernel Address Space support" | ||
63 | default y | ||
64 | help | ||
65 | This option controls whether skas (separate kernel address space) | ||
66 | support is compiled in. If you have applied the skas patch to the | ||
67 | host, then you certainly want to say Y here (and consider saying N | ||
68 | to CONFIG_MODE_TT). Otherwise, it is safe to say Y. Disabling this | ||
69 | option will shrink the UML binary slightly. | ||
70 | |||
71 | source "arch/um/Kconfig_arch" | ||
72 | |||
73 | config LD_SCRIPT_STATIC | ||
74 | bool | ||
75 | default y | ||
76 | depends on MODE_TT || STATIC_LINK | ||
77 | |||
78 | config LD_SCRIPT_DYN | ||
79 | bool | ||
80 | default y | ||
81 | depends on !LD_SCRIPT_STATIC | ||
82 | |||
83 | config NET | ||
84 | bool "Networking support" | ||
85 | help | ||
86 | Unless you really know what you are doing, you should say Y here. | ||
87 | The reason is that some programs need kernel networking support even | ||
88 | when running on a stand-alone machine that isn't connected to any | ||
89 | other computer. If you are upgrading from an older kernel, you | ||
90 | should consider updating your networking tools too because changes | ||
91 | in the kernel and the tools often go hand in hand. The tools are | ||
92 | contained in the package net-tools, the location and version number | ||
93 | of which are given in <file:Documentation/Changes>. | ||
94 | |||
95 | For a general introduction to Linux networking, it is highly | ||
96 | recommended to read the NET-HOWTO, available from | ||
97 | <http://www.tldp.org/docs.html#howto>. | ||
98 | |||
99 | |||
100 | source "fs/Kconfig.binfmt" | ||
101 | |||
102 | config HOSTFS | ||
103 | tristate "Host filesystem" | ||
104 | help | ||
105 | While the User-Mode Linux port uses its own root file system for | ||
106 | booting and normal file access, this module lets the UML user | ||
107 | access files stored on the host. It does not require any | ||
108 | network connection between the Host and UML. An example use of | ||
109 | this might be: | ||
110 | |||
111 | mount none /tmp/fromhost -t hostfs -o /tmp/umlshare | ||
112 | |||
113 | where /tmp/fromhost is an empty directory inside UML and | ||
114 | /tmp/umlshare is a directory on the host with files the UML user | ||
115 | wishes to access. | ||
116 | |||
117 | For more information, see | ||
118 | <http://user-mode-linux.sourceforge.net/hostfs.html>. | ||
119 | |||
120 | If you'd like to be able to work with files stored on the host, | ||
121 | say Y or M here; otherwise say N. | ||
122 | |||
123 | config HPPFS | ||
124 | tristate "HoneyPot ProcFS (EXPERIMENTAL)" | ||
125 | depends on BROKEN | ||
126 | help | ||
127 | hppfs (HoneyPot ProcFS) is a filesystem which allows UML /proc | ||
128 | entries to be overridden, removed, or fabricated from the host. | ||
129 | Its purpose is to allow a UML to appear to be a physical machine | ||
130 | by removing or changing anything in /proc which gives away the | ||
131 | identity of a UML. | ||
132 | |||
133 | See <http://user-mode-linux.sf.net/hppfs.html> for more information. | ||
134 | |||
135 | You only need this if you are setting up a UML honeypot. Otherwise, | ||
136 | it is safe to say 'N' here. | ||
137 | |||
138 | If you are actively using it, please ask for it to be fixed. In this | ||
139 | moment, it does not work on 2.6 (it works somehow on 2.4). | ||
140 | |||
141 | config MCONSOLE | ||
142 | bool "Management console" | ||
143 | default y | ||
144 | help | ||
145 | The user mode linux management console is a low-level interface to | ||
146 | the kernel, somewhat like the i386 SysRq interface. Since there is | ||
147 | a full-blown operating system running under every user mode linux | ||
148 | instance, there is much greater flexibility possible than with the | ||
149 | SysRq mechanism. | ||
150 | |||
151 | If you answer 'Y' to this option, to use this feature, you need the | ||
152 | mconsole client (called uml_mconsole) which is present in CVS in | ||
153 | 2.4.5-9um and later (path /tools/mconsole), and is also in the | ||
154 | distribution RPM package in 2.4.6 and later. | ||
155 | |||
156 | It is safe to say 'Y' here. | ||
157 | |||
158 | config MAGIC_SYSRQ | ||
159 | bool "Magic SysRq key" | ||
160 | depends on MCONSOLE | ||
161 | ---help--- | ||
162 | If you say Y here, you will have some control over the system even | ||
163 | if the system crashes for example during kernel debugging (e.g., you | ||
164 | will be able to flush the buffer cache to disk, reboot the system | ||
165 | immediately or dump some status information). A key for each of the | ||
166 | possible requests is provided. | ||
167 | |||
168 | This is the feature normally accomplished by pressing a key | ||
169 | while holding SysRq (Alt+PrintScreen). | ||
170 | |||
171 | On UML, this is accomplished by sending a "sysrq" command with | ||
172 | mconsole, followed by the letter for the requested command. | ||
173 | |||
174 | The keys are documented in <file:Documentation/sysrq.txt>. Don't say Y | ||
175 | unless you really know what this hack does. | ||
176 | |||
177 | config HOST_2G_2G | ||
178 | bool "2G/2G host address space split" | ||
179 | default n | ||
180 | help | ||
181 | This is needed when the host on which you run has a 2G/2G memory | ||
182 | split, instead of the customary 3G/1G. | ||
183 | |||
184 | Note that to enable such a host | ||
185 | configuration, which makes sense only in some cases, you need special | ||
186 | host patches. | ||
187 | |||
188 | So, if you do not know what to do here, say 'N'. | ||
189 | |||
190 | config SMP | ||
191 | bool "Symmetric multi-processing support (EXPERIMENTAL)" | ||
192 | default n | ||
193 | depends on MODE_TT && EXPERIMENTAL | ||
194 | help | ||
195 | This option enables UML SMP support. | ||
196 | It is NOT related to having a real SMP box. Not directly, at least. | ||
197 | |||
198 | UML implements virtual SMP by allowing as many processes to run | ||
199 | simultaneously on the host as there are virtual processors configured. | ||
200 | |||
201 | Obviously, if the host is a uniprocessor, those processes will | ||
202 | timeshare, but, inside UML, will appear to be running simultaneously. | ||
203 | If the host is a multiprocessor, then UML processes may run | ||
204 | simultaneously, depending on the host scheduler. | ||
205 | |||
206 | This, however, is supported only in TT mode. So, if you use the SKAS | ||
207 | patch on your host, switching to TT mode and enabling SMP usually gives | ||
208 | you worse performances. | ||
209 | Also, since the support for SMP has been under-developed, there could | ||
210 | be some bugs being exposed by enabling SMP. | ||
211 | |||
212 | If you don't know what to do, say N. | ||
213 | |||
214 | config NR_CPUS | ||
215 | int "Maximum number of CPUs (2-32)" | ||
216 | range 2 32 | ||
217 | depends on SMP | ||
218 | default "32" | ||
219 | |||
220 | config NEST_LEVEL | ||
221 | int "Nesting level" | ||
222 | default "0" | ||
223 | help | ||
224 | This is set to the number of layers of UMLs that this UML will be run | ||
225 | in. Normally, this is zero, meaning that it will run directly on the | ||
226 | host. Setting it to one will build a UML that can run inside a UML | ||
227 | that is running on the host. Generally, if you intend this UML to run | ||
228 | inside another UML, set CONFIG_NEST_LEVEL to one more than the host | ||
229 | UML. | ||
230 | |||
231 | Note that if the hosting UML has its CONFIG_KERNEL_HALF_GIGS set to | ||
232 | greater than one, then the guest UML should have its CONFIG_NEST_LEVEL | ||
233 | set to the host's CONFIG_NEST_LEVEL + CONFIG_KERNEL_HALF_GIGS. | ||
234 | Only change this if you are running nested UMLs. | ||
235 | |||
236 | config KERNEL_HALF_GIGS | ||
237 | int "Kernel address space size (in .5G units)" | ||
238 | default "1" | ||
239 | help | ||
240 | This determines the amount of address space that UML will allocate for | ||
241 | its own, measured in half Gigabyte units. The default is 1. | ||
242 | Change this only if you need to boot UML with an unusually large amount | ||
243 | of physical memory. | ||
244 | |||
245 | config HIGHMEM | ||
246 | bool "Highmem support" | ||
247 | |||
248 | config KERNEL_STACK_ORDER | ||
249 | int "Kernel stack size order" | ||
250 | default 2 | ||
251 | help | ||
252 | This option determines the size of UML kernel stacks. They will | ||
253 | be 1 << order pages. The default is OK unless you're running Valgrind | ||
254 | on UML, in which case, set this to 3. | ||
255 | |||
256 | config UML_REAL_TIME_CLOCK | ||
257 | bool "Real-time Clock" | ||
258 | default y | ||
259 | help | ||
260 | This option makes UML time deltas match wall clock deltas. This should | ||
261 | normally be enabled. The exception would be if you are debugging with | ||
262 | UML and spend long times with UML stopped at a breakpoint. In this | ||
263 | case, when UML is restarted, it will call the timer enough times to make | ||
264 | up for the time spent at the breakpoint. This could result in a | ||
265 | noticable lag. If this is a problem, then disable this option. | ||
266 | |||
267 | endmenu | ||
268 | |||
269 | source "init/Kconfig" | ||
270 | |||
271 | source "drivers/base/Kconfig" | ||
272 | |||
273 | source "arch/um/Kconfig_char" | ||
274 | |||
275 | source "drivers/block/Kconfig" | ||
276 | |||
277 | config NETDEVICES | ||
278 | bool | ||
279 | default NET | ||
280 | |||
281 | source "arch/um/Kconfig_net" | ||
282 | |||
283 | source "net/Kconfig" | ||
284 | |||
285 | source "fs/Kconfig" | ||
286 | |||
287 | source "security/Kconfig" | ||
288 | |||
289 | source "crypto/Kconfig" | ||
290 | |||
291 | source "lib/Kconfig" | ||
292 | |||
293 | menu "SCSI support" | ||
294 | depends on BROKEN | ||
295 | |||
296 | config SCSI | ||
297 | tristate "SCSI support" | ||
298 | |||
299 | # This gives us free_dma, which scsi.c wants. | ||
300 | config GENERIC_ISA_DMA | ||
301 | bool | ||
302 | depends on SCSI | ||
303 | default y | ||
304 | |||
305 | source "arch/um/Kconfig_scsi" | ||
306 | |||
307 | endmenu | ||
308 | |||
309 | source "drivers/md/Kconfig" | ||
310 | |||
311 | if BROKEN | ||
312 | source "drivers/mtd/Kconfig" | ||
313 | endif | ||
314 | |||
315 | #This is just to shut up some Kconfig warnings, so no prompt. | ||
316 | config INPUT | ||
317 | bool | ||
318 | default n | ||
319 | |||
320 | source "arch/um/Kconfig.debug" | ||