aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX10
-rw-r--r--Documentation/ABI/obsolete/o2cb11
-rw-r--r--Documentation/ABI/stable/o2cb10
-rw-r--r--Documentation/ABI/testing/sysfs-ocfs289
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/DocBook/kgdb.tmpl447
-rw-r--r--Documentation/SubmittingPatches54
-rw-r--r--Documentation/debugging-via-ohci1394.txt16
-rw-r--r--Documentation/feature-removal-schedule.txt12
-rw-r--r--Documentation/filesystems/00-INDEX6
-rw-r--r--Documentation/filesystems/nfsroot.txt (renamed from Documentation/nfsroot.txt)0
-rw-r--r--Documentation/filesystems/rpc-cache.txt (renamed from Documentation/rpc-cache.txt)0
-rw-r--r--Documentation/filesystems/seq_file.txt283
-rw-r--r--Documentation/filesystems/xfs.txt15
-rw-r--r--Documentation/i386/boot.txt28
-rw-r--r--Documentation/ide/ide.txt47
-rw-r--r--Documentation/ide/warm-plug-howto.txt13
-rw-r--r--Documentation/kernel-parameters.txt37
-rw-r--r--Documentation/networking/can.txt8
-rw-r--r--Documentation/s390/s390dbf.txt21
-rw-r--r--Documentation/scheduler/00-INDEX2
-rw-r--r--Documentation/scheduler/sched-rt-group.txt (renamed from Documentation/sched-rt-group.txt)0
-rw-r--r--Documentation/spi/spi-summary15
-rw-r--r--Documentation/spinlocks.txt22
-rw-r--r--Documentation/timers/highres.txt (renamed from Documentation/hrtimers/highres.txt)2
-rw-r--r--Documentation/timers/hrtimers.txt (renamed from Documentation/hrtimers/hrtimers.txt)0
-rw-r--r--Documentation/timers/timer_stats.txt (renamed from Documentation/hrtimer/timer_stats.txt)0
-rw-r--r--Documentation/vm/hugetlbpage.txt7
-rw-r--r--Documentation/x86/pat.txt100
-rw-r--r--Documentation/x86_64/boot-options.txt5
30 files changed, 1177 insertions, 85 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index fc8e7c7d182f..f7923a42e769 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -167,10 +167,8 @@ highuid.txt
167 - notes on the change from 16 bit to 32 bit user/group IDs. 167 - notes on the change from 16 bit to 32 bit user/group IDs.
168hpet.txt 168hpet.txt
169 - High Precision Event Timer Driver for Linux. 169 - High Precision Event Timer Driver for Linux.
170hrtimer/ 170timers/
171 - info on the timer_stats debugging facility for timer (ab)use. 171 - info on the timer related topics
172hrtimers/
173 - info on the hrtimers subsystem for high-resolution kernel timers.
174hw_random.txt 172hw_random.txt
175 - info on Linux support for random number generator in i8xx chipsets. 173 - info on Linux support for random number generator in i8xx chipsets.
176hwmon/ 174hwmon/
@@ -271,8 +269,6 @@ netlabel/
271 - directory with information on the NetLabel subsystem. 269 - directory with information on the NetLabel subsystem.
272networking/ 270networking/
273 - directory with info on various aspects of networking with Linux. 271 - directory with info on various aspects of networking with Linux.
274nfsroot.txt
275 - short guide on setting up a diskless box with NFS root filesystem.
276nmi_watchdog.txt 272nmi_watchdog.txt
277 - info on NMI watchdog for SMP systems. 273 - info on NMI watchdog for SMP systems.
278nommu-mmap.txt 274nommu-mmap.txt
@@ -321,8 +317,6 @@ robust-futexes.txt
321 - a description of what robust futexes are. 317 - a description of what robust futexes are.
322rocket.txt 318rocket.txt
323 - info on the Comtrol RocketPort multiport serial driver. 319 - info on the Comtrol RocketPort multiport serial driver.
324rpc-cache.txt
325 - introduction to the caching mechanisms in the sunrpc layer.
326rt-mutex-design.txt 320rt-mutex-design.txt
327 - description of the RealTime mutex implementation design. 321 - description of the RealTime mutex implementation design.
328rt-mutex.txt 322rt-mutex.txt
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb
new file mode 100644
index 000000000000..9c49d8e6c0cc
--- /dev/null
+++ b/Documentation/ABI/obsolete/o2cb
@@ -0,0 +1,11 @@
1What: /sys/o2cb symlink
2Date: Dec 2005
3KernelVersion: 2.6.16
4Contact: ocfs2-devel@oss.oracle.com
5Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will
6 be removed when new versions of ocfs2-tools which know to look
7 in /sys/fs/o2cb are sufficiently prevalent. Don't code new
8 software to look here, it should try /sys/fs/o2cb instead.
9 See Documentation/ABI/stable/o2cb for more information on usage.
10Users: ocfs2-tools. It's sufficient to mail proposed changes to
11 ocfs2-devel@oss.oracle.com.
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb
new file mode 100644
index 000000000000..5eb1545e0b8d
--- /dev/null
+++ b/Documentation/ABI/stable/o2cb
@@ -0,0 +1,10 @@
1What: /sys/fs/o2cb/ (was /sys/o2cb)
2Date: Dec 2005
3KernelVersion: 2.6.16
4Contact: ocfs2-devel@oss.oracle.com
5Description: Ocfs2-tools looks at 'interface-revision' for versioning
6 information. Each logmask/ file controls a set of debug prints
7 and can be written into with the strings "allow", "deny", or
8 "off". Reading the file returns the current state.
9Users: ocfs2-tools. It's sufficient to mail proposed changes to
10 ocfs2-devel@oss.oracle.com.
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2
new file mode 100644
index 000000000000..b7cc516a8a8a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ocfs2
@@ -0,0 +1,89 @@
1What: /sys/fs/ocfs2/
2Date: April 2008
3Contact: ocfs2-devel@oss.oracle.com
4Description:
5 The /sys/fs/ocfs2 directory contains knobs used by the
6 ocfs2-tools to interact with the filesystem.
7
8What: /sys/fs/ocfs2/max_locking_protocol
9Date: April 2008
10Contact: ocfs2-devel@oss.oracle.com
11Description:
12 The /sys/fs/ocfs2/max_locking_protocol file displays version
13 of ocfs2 locking supported by the filesystem. This version
14 covers how ocfs2 uses distributed locking between cluster
15 nodes.
16
17 The protocol version has a major and minor number. Two
18 cluster nodes can interoperate if they have an identical
19 major number and an overlapping minor number - thus,
20 a node with version 1.10 can interoperate with a node
21 sporting version 1.8, as long as both use the 1.8 protocol.
22
23 Reading from this file returns a single line, the major
24 number and minor number joined by a period, eg "1.10".
25
26 This file is read-only. The value is compiled into the
27 driver.
28
29What: /sys/fs/ocfs2/loaded_cluster_plugins
30Date: April 2008
31Contact: ocfs2-devel@oss.oracle.com
32Description:
33 The /sys/fs/ocfs2/loaded_cluster_plugins file describes
34 the available plugins to support ocfs2 cluster operation.
35 A cluster plugin is required to use ocfs2 in a cluster.
36 There are currently two available plugins:
37
38 * 'o2cb' - The classic o2cb cluster stack that ocfs2 has
39 used since its inception.
40 * 'user' - A plugin supporting userspace cluster software
41 in conjunction with fs/dlm.
42
43 Reading from this file returns the names of all loaded
44 plugins, one per line.
45
46 This file is read-only. Its contents may change as
47 plugins are loaded or removed.
48
49What: /sys/fs/ocfs2/active_cluster_plugin
50Date: April 2008
51Contact: ocfs2-devel@oss.oracle.com
52Description:
53 The /sys/fs/ocfs2/active_cluster_plugin displays which
54 cluster plugin is currently in use by the filesystem.
55 The active plugin will appear in the loaded_cluster_plugins
56 file as well. Only one plugin can be used at a time.
57
58 Reading from this file returns the name of the active plugin
59 on a single line.
60
61 This file is read-only. Which plugin is active depends on
62 the cluster stack in use. The contents may change
63 when all filesystems are unmounted and the cluster stack
64 is changed.
65
66What: /sys/fs/ocfs2/cluster_stack
67Date: April 2008
68Contact: ocfs2-devel@oss.oracle.com
69Description:
70 The /sys/fs/ocfs2/cluster_stack file contains the name
71 of current ocfs2 cluster stack. This value is set by
72 userspace tools when bringing the cluster stack online.
73
74 Cluster stack names are 4 characters in length.
75
76 When the 'o2cb' cluster stack is used, the 'o2cb' cluster
77 plugin is active. All other cluster stacks use the 'user'
78 cluster plugin.
79
80 Reading from this file returns the name of the current
81 cluster stack on a single line.
82
83 Writing a new stack name to this file changes the current
84 cluster stack unless there are mounted ocfs2 filesystems.
85 If there are mounted filesystems, attempts to change the
86 stack return an error.
87
88Users:
89 ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 300e1707893f..e471bc466a7e 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -9,7 +9,7 @@
9DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ 9DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ 10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
11 procfs-guide.xml writing_usb_driver.xml networking.xml \ 11 procfs-guide.xml writing_usb_driver.xml networking.xml \
12 kernel-api.xml filesystems.xml lsm.xml usb.xml \ 12 kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
13 gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ 13 gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
14 genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml 14 genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
15 15
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
new file mode 100644
index 000000000000..97618bed4d65
--- /dev/null
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -0,0 +1,447 @@
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
4
5<book id="kgdbOnLinux">
6 <bookinfo>
7 <title>Using kgdb and the kgdb Internals</title>
8
9 <authorgroup>
10 <author>
11 <firstname>Jason</firstname>
12 <surname>Wessel</surname>
13 <affiliation>
14 <address>
15 <email>jason.wessel@windriver.com</email>
16 </address>
17 </affiliation>
18 </author>
19 </authorgroup>
20
21 <authorgroup>
22 <author>
23 <firstname>Tom</firstname>
24 <surname>Rini</surname>
25 <affiliation>
26 <address>
27 <email>trini@kernel.crashing.org</email>
28 </address>
29 </affiliation>
30 </author>
31 </authorgroup>
32
33 <authorgroup>
34 <author>
35 <firstname>Amit S.</firstname>
36 <surname>Kale</surname>
37 <affiliation>
38 <address>
39 <email>amitkale@linsyssoft.com</email>
40 </address>
41 </affiliation>
42 </author>
43 </authorgroup>
44
45 <copyright>
46 <year>2008</year>
47 <holder>Wind River Systems, Inc.</holder>
48 </copyright>
49 <copyright>
50 <year>2004-2005</year>
51 <holder>MontaVista Software, Inc.</holder>
52 </copyright>
53 <copyright>
54 <year>2004</year>
55 <holder>Amit S. Kale</holder>
56 </copyright>
57
58 <legalnotice>
59 <para>
60 This file is licensed under the terms of the GNU General Public License
61 version 2. This program is licensed "as is" without any warranty of any
62 kind, whether express or implied.
63 </para>
64
65 </legalnotice>
66 </bookinfo>
67
68<toc></toc>
69 <chapter id="Introduction">
70 <title>Introduction</title>
71 <para>
72 kgdb is a source level debugger for linux kernel. It is used along
73 with gdb to debug a linux kernel. The expectation is that gdb can
74 be used to "break in" to the kernel to inspect memory, variables
75 and look through a cal stack information similar to what an
76 application developer would use gdb for. It is possible to place
77 breakpoints in kernel code and perform some limited execution
78 stepping.
79 </para>
80 <para>
81 Two machines are required for using kgdb. One of these machines is a
82 development machine and the other is a test machine. The kernel
83 to be debugged runs on the test machine. The development machine
84 runs an instance of gdb against the vmlinux file which contains
85 the symbols (not boot image such as bzImage, zImage, uImage...).
86 In gdb the developer specifies the connection parameters and
87 connects to kgdb. Depending on which kgdb I/O modules exist in
88 the kernel for a given architecture, it may be possible to debug
89 the test machine's kernel with the development machine using a
90 rs232 or ethernet connection.
91 </para>
92 </chapter>
93 <chapter id="CompilingAKernel">
94 <title>Compiling a kernel</title>
95 <para>
96 To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
97 and then select "KGDB: kernel debugging with remote gdb".
98 </para>
99 <para>
100 Next you should choose one of more I/O drivers to interconnect debugging
101 host and debugged target. Early boot debugging requires a KGDB
102 I/O driver that supports early debugging and the driver must be
103 built into the kernel directly. Kgdb I/O driver configuration
104 takes place via kernel or module parameters, see following
105 chapter.
106 </para>
107 <para>
108 The kgdb test compile options are described in the kgdb test suite chapter.
109 </para>
110
111 </chapter>
112 <chapter id="EnableKGDB">
113 <title>Enable kgdb for debugging</title>
114 <para>
115 In order to use kgdb you must activate it by passing configuration
116 information to one of the kgdb I/O drivers. If you do not pass any
117 configuration information kgdb will not do anything at all. Kgdb
118 will only actively hook up to the kernel trap hooks if a kgdb I/O
119 driver is loaded and configured. If you unconfigure a kgdb I/O
120 driver, kgdb will unregister all the kernel hook points.
121 </para>
122 <para>
123 All drivers can be reconfigured at run time, if
124 <symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol>
125 are enabled, by echo'ing a new config string to
126 <constant>/sys/module/&lt;driver&gt;/parameter/&lt;option&gt;</constant>.
127 The driver can be unconfigured by passing an empty string. You cannot
128 change the configuration while the debugger is attached. Make sure
129 to detach the debugger with the <constant>detach</constant> command
130 prior to trying unconfigure a kgdb I/O driver.
131 </para>
132 <sect1 id="kgdbwait">
133 <title>Kernel parameter: kgdbwait</title>
134 <para>
135 The Kernel command line option <constant>kgdbwait</constant> makes
136 kgdb wait for a debugger connection during booting of a kernel. You
137 can only use this option you compiled a kgdb I/O driver into the
138 kernel and you specified the I/O driver configuration as a kernel
139 command line option. The kgdbwait parameter should always follow the
140 configuration parameter for the kgdb I/O driver in the kernel
141 command line else the I/O driver will not be configured prior to
142 asking the kernel to use it to wait.
143 </para>
144 <para>
145 The kernel will stop and wait as early as the I/O driver and
146 architecture will allow when you use this option. If you build the
147 kgdb I/O driver as a kernel module kgdbwait will not do anything.
148 </para>
149 </sect1>
150 <sect1 id="kgdboc">
151 <title>Kernel parameter: kgdboc</title>
152 <para>
153 The kgdboc driver was originally an abbreviation meant to stand for
154 "kgdb over console". Kgdboc is designed to work with a single
155 serial port. It was meant to cover the circumstance
156 where you wanted to use a serial console as your primary console as
157 well as using it to perform kernel debugging. Of course you can
158 also use kgdboc without assigning a console to the same port.
159 </para>
160 <sect2 id="UsingKgdboc">
161 <title>Using kgdboc</title>
162 <para>
163 You can configure kgdboc via sysfs or a module or kernel boot line
164 parameter depending on if you build with CONFIG_KGDBOC as a module
165 or built-in.
166 <orderedlist>
167 <listitem><para>From the module load or build-in</para>
168 <para><constant>kgdboc=&lt;tty-device&gt;,[baud]</constant></para>
169 <para>
170 The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant>
171 </para>
172 </listitem>
173 <listitem><para>From sysfs</para>
174 <para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para>
175 </listitem>
176 </orderedlist>
177 </para>
178 <para>
179 NOTE: Kgdboc does not support interrupting the target via the
180 gdb remote protocol. You must manually send a sysrq-g unless you
181 have a proxy that splits console output to a terminal problem and
182 has a separate port for the debugger to connect to that sends the
183 sysrq-g for you.
184 </para>
185 <para>When using kgdboc with no debugger proxy, you can end up
186 connecting the debugger for one of two entry points. If an
187 exception occurs after you have loaded kgdboc a message should print
188 on the console stating it is waiting for the debugger. In case you
189 disconnect your terminal program and then connect the debugger in
190 its place. If you want to interrupt the target system and forcibly
191 enter a debug session you have to issue a Sysrq sequence and then
192 type the letter <constant>g</constant>. Then you disconnect the
193 terminal session and connect gdb. Your options if you don't like
194 this are to hack gdb to send the sysrq-g for you as well as on the
195 initial connect, or to use a debugger proxy that allows an
196 unmodified gdb to do the debugging.
197 </para>
198 </sect2>
199 </sect1>
200 <sect1 id="kgdbcon">
201 <title>Kernel parameter: kgdbcon</title>
202 <para>
203 Kgdb supports using the gdb serial protocol to send console messages
204 to the debugger when the debugger is connected and running. There
205 are two ways to activate this feature.
206 <orderedlist>
207 <listitem><para>Activate with the kernel command line option:</para>
208 <para><constant>kgdbcon</constant></para>
209 </listitem>
210 <listitem><para>Use sysfs before configuring an io driver</para>
211 <para>
212 <constant>echo 1 &gt; /sys/module/kgdb/parameters/kgdb_use_con</constant>
213 </para>
214 <para>
215 NOTE: If you do this after you configure the kgdb I/O driver, the
216 setting will not take effect until the next point the I/O is
217 reconfigured.
218 </para>
219 </listitem>
220 </orderedlist>
221 </para>
222 <para>
223 IMPORTANT NOTE: Using this option with kgdb over the console
224 (kgdboc) or kgdb over ethernet (kgdboe) is not supported.
225 </para>
226 </sect1>
227 </chapter>
228 <chapter id="ConnectingGDB">
229 <title>Connecting gdb</title>
230 <para>
231 If you are using kgdboc, you need to have used kgdbwait as a boot
232 argument, issued a sysrq-g, or the system you are going to debug
233 has already taken an exception and is waiting for the debugger to
234 attach before you can connect gdb.
235 </para>
236 <para>
237 If you are not using different kgdb I/O driver other than kgdboc,
238 you should be able to connect and the target will automatically
239 respond.
240 </para>
241 <para>
242 Example (using a serial port):
243 </para>
244 <programlisting>
245 % gdb ./vmlinux
246 (gdb) set remotebaud 115200
247 (gdb) target remote /dev/ttyS0
248 </programlisting>
249 <para>
250 Example (kgdb to a terminal server):
251 </para>
252 <programlisting>
253 % gdb ./vmlinux
254 (gdb) target remote udp:192.168.2.2:6443
255 </programlisting>
256 <para>
257 Example (kgdb over ethernet):
258 </para>
259 <programlisting>
260 % gdb ./vmlinux
261 (gdb) target remote udp:192.168.2.2:6443
262 </programlisting>
263 <para>
264 Once connected, you can debug a kernel the way you would debug an
265 application program.
266 </para>
267 <para>
268 If you are having problems connecting or something is going
269 seriously wrong while debugging, it will most often be the case
270 that you want to enable gdb to be verbose about its target
271 communications. You do this prior to issuing the <constant>target
272 remote</constant> command by typing in: <constant>set remote debug 1</constant>
273 </para>
274 </chapter>
275 <chapter id="KGDBTestSuite">
276 <title>kgdb Test Suite</title>
277 <para>
278 When kgdb is enabled in the kernel config you can also elect to
279 enable the config parameter KGDB_TESTS. Turning this on will
280 enable a special kgdb I/O module which is designed to test the
281 kgdb internal functions.
282 </para>
283 <para>
284 The kgdb tests are mainly intended for developers to test the kgdb
285 internals as well as a tool for developing a new kgdb architecture
286 specific implementation. These tests are not really for end users
287 of the Linux kernel. The primary source of documentation would be
288 to look in the drivers/misc/kgdbts.c file.
289 </para>
290 <para>
291 The kgdb test suite can also be configured at compile time to run
292 the core set of tests by setting the kernel config parameter
293 KGDB_TESTS_ON_BOOT. This particular option is aimed at automated
294 regression testing and does not require modifying the kernel boot
295 config arguments. If this is turned on, the kgdb test suite can
296 be disabled by specifying "kgdbts=" as a kernel boot argument.
297 </para>
298 </chapter>
299 <chapter id="CommonBackEndReq">
300 <title>KGDB Internals</title>
301 <sect1 id="kgdbArchitecture">
302 <title>Architecture Specifics</title>
303 <para>
304 Kgdb is organized into three basic components:
305 <orderedlist>
306 <listitem><para>kgdb core</para>
307 <para>
308 The kgdb core is found in kernel/kgdb.c. It contains:
309 <itemizedlist>
310 <listitem><para>All the logic to implement the gdb serial protocol</para></listitem>
311 <listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem>
312 <listitem><para>The API to talk to the kgdb I/O drivers</para></listitem>
313 <listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem>
314 <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
315 <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
316 </itemizedlist>
317 </para>
318 </listitem>
319 <listitem><para>kgdb arch specific implementation</para>
320 <para>
321 This implementation is generally found in arch/*/kernel/kgdb.c.
322 As an example, arch/x86/kernel/kgdb.c contains the specifics to
323 implement HW breakpoint as well as the initialization to
324 dynamically register and unregister for the trap handlers on
325 this architecture. The arch specific portion implements:
326 <itemizedlist>
327 <listitem><para>contains an arch specific trap catcher which
328 invokes kgdb_handle_exception() to start kgdb about doing its
329 work</para></listitem>
330 <listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem>
331 <listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
332 <listitem><para>Any special exception handling and cleanup</para></listitem>
333 <listitem><para>NMI exception handling and cleanup</para></listitem>
334 <listitem><para>(optional)HW breakpoints</para></listitem>
335 </itemizedlist>
336 </para>
337 </listitem>
338 <listitem><para>kgdb I/O driver</para>
339 <para>
340 Each kgdb I/O driver has to provide an implemenation for the following:
341 <itemizedlist>
342 <listitem><para>configuration via builtin or module</para></listitem>
343 <listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem>
344 <listitem><para>read and write character interface</para></listitem>
345 <listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem>
346 <listitem><para>(optional) Early debug methodology</para></listitem>
347 </itemizedlist>
348 Any given kgdb I/O driver has to operate very closely with the
349 hardware and must do it in such a way that does not enable
350 interrupts or change other parts of the system context without
351 completely restoring them. The kgdb core will repeatedly "poll"
352 a kgdb I/O driver for characters when it needs input. The I/O
353 driver is expected to return immediately if there is no data
354 available. Doing so allows for the future possibility to touch
355 watch dog hardware in such a way as to have a target system not
356 reset when these are enabled.
357 </para>
358 </listitem>
359 </orderedlist>
360 </para>
361 <para>
362 If you are intent on adding kgdb architecture specific support
363 for a new architecture, the architecture should define
364 <constant>HAVE_ARCH_KGDB</constant> in the architecture specific
365 Kconfig file. This will enable kgdb for the architecture, and
366 at that point you must create an architecture specific kgdb
367 implementation.
368 </para>
369 <para>
370 There are a few flags which must be set on every architecture in
371 their &lt;asm/kgdb.h&gt; file. These are:
372 <itemizedlist>
373 <listitem>
374 <para>
375 NUMREGBYTES: The size in bytes of all of the registers, so
376 that we can ensure they will all fit into a packet.
377 </para>
378 <para>
379 BUFMAX: The size in bytes of the buffer GDB will read into.
380 This must be larger than NUMREGBYTES.
381 </para>
382 <para>
383 CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
384 flush_cache_range or flush_icache_range. On some architectures,
385 these functions may not be safe to call on SMP since we keep other
386 CPUs in a holding pattern.
387 </para>
388 </listitem>
389 </itemizedlist>
390 </para>
391 <para>
392 There are also the following functions for the common backend,
393 found in kernel/kgdb.c, that must be supplied by the
394 architecture-specific backend unless marked as (optional), in
395 which case a default function maybe used if the architecture
396 does not need to provide a specific implementation.
397 </para>
398!Iinclude/linux/kgdb.h
399 </sect1>
400 <sect1 id="kgdbocDesign">
401 <title>kgdboc internals</title>
402 <para>
403 The kgdboc driver is actually a very thin driver that relies on the
404 underlying low level to the hardware driver having "polling hooks"
405 which the to which the tty driver is attached. In the initial
406 implementation of kgdboc it the serial_core was changed to expose a
407 low level uart hook for doing polled mode reading and writing of a
408 single character while in an atomic context. When kgdb makes an I/O
409 request to the debugger, kgdboc invokes a call back in the serial
410 core which in turn uses the call back in the uart driver. It is
411 certainly possible to extend kgdboc to work with non-uart based
412 consoles in the future.
413 </para>
414 <para>
415 When using kgdboc with a uart, the uart driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
416#ifdef CONFIG_CONSOLE_POLL
417 .poll_get_char = serial8250_get_poll_char,
418 .poll_put_char = serial8250_put_poll_char,
419#endif
420 </programlisting>
421 Any implementation specifics around creating a polling driver use the
422 <constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above.
423 Keep in mind that polling hooks have to be implemented in such a way
424 that they can be called from an atomic context and have to restore
425 the state of the uart chip on return such that the system can return
426 to normal when the debugger detaches. You need to be very careful
427 with any kind of lock you consider, because failing here is most
428 going to mean pressing the reset button.
429 </para>
430 </sect1>
431 </chapter>
432 <chapter id="credits">
433 <title>Credits</title>
434 <para>
435 The following people have contributed to this document:
436 <orderedlist>
437 <listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem>
438 <listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem>
439 </orderedlist>
440 In March 2008 this document was completely rewritten by:
441 <itemizedlist>
442 <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem>
443 </itemizedlist>
444 </para>
445 </chapter>
446</book>
447
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 47a539c7642d..1fc4e7144dce 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -328,7 +328,7 @@ now, but you can do this to mark internal company procedures or just
328point out some special detail about the sign-off. 328point out some special detail about the sign-off.
329 329
330 330
33113) When to use Acked-by: 33113) When to use Acked-by: and Cc:
332 332
333The Signed-off-by: tag indicates that the signer was involved in the 333The Signed-off-by: tag indicates that the signer was involved in the
334development of the patch, or that he/she was in the patch's delivery path. 334development of the patch, or that he/she was in the patch's delivery path.
@@ -349,11 +349,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch.
349For example, if a patch affects multiple subsystems and has an Acked-by: from 349For example, if a patch affects multiple subsystems and has an Acked-by: from
350one subsystem maintainer then this usually indicates acknowledgement of just 350one subsystem maintainer then this usually indicates acknowledgement of just
351the part which affects that maintainer's code. Judgement should be used here. 351the part which affects that maintainer's code. Judgement should be used here.
352 When in doubt people should refer to the original discussion in the mailing 352When in doubt people should refer to the original discussion in the mailing
353list archives. 353list archives.
354 354
355If a person has had the opportunity to comment on a patch, but has not
356provided such comments, you may optionally add a "Cc:" tag to the patch.
357This is the only tag which might be added without an explicit action by the
358person it names. This tag documents that potentially interested parties
359have been included in the discussion
355 360
35614) The canonical patch format 361
36214) Using Test-by: and Reviewed-by:
363
364A Tested-by: tag indicates that the patch has been successfully tested (in
365some environment) by the person named. This tag informs maintainers that
366some testing has been performed, provides a means to locate testers for
367future patches, and ensures credit for the testers.
368
369Reviewed-by:, instead, indicates that the patch has been reviewed and found
370acceptable according to the Reviewer's Statement:
371
372 Reviewer's statement of oversight
373
374 By offering my Reviewed-by: tag, I state that:
375
376 (a) I have carried out a technical review of this patch to
377 evaluate its appropriateness and readiness for inclusion into
378 the mainline kernel.
379
380 (b) Any problems, concerns, or questions relating to the patch
381 have been communicated back to the submitter. I am satisfied
382 with the submitter's response to my comments.
383
384 (c) While there may be things that could be improved with this
385 submission, I believe that it is, at this time, (1) a
386 worthwhile modification to the kernel, and (2) free of known
387 issues which would argue against its inclusion.
388
389 (d) While I have reviewed the patch and believe it to be sound, I
390 do not (unless explicitly stated elsewhere) make any
391 warranties or guarantees that it will achieve its stated
392 purpose or function properly in any given situation.
393
394A Reviewed-by tag is a statement of opinion that the patch is an
395appropriate modification of the kernel without any remaining serious
396technical issues. Any interested reviewer (who has done the work) can
397offer a Reviewed-by tag for a patch. This tag serves to give credit to
398reviewers and to inform maintainers of the degree of review which has been
399done on the patch. Reviewed-by: tags, when supplied by reviewers known to
400understand the subject area and to perform thorough reviews, will normally
401increase the liklihood of your patch getting into the kernel.
402
403
40415) The canonical patch format
357 405
358The canonical patch subject line is: 406The canonical patch subject line is:
359 407
diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt
index c360d4e91b48..59a91e5c6909 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -41,15 +41,19 @@ to a working state and enables physical DMA by default for all remote nodes.
41This can be turned off by ohci1394's module parameter phys_dma=0. 41This can be turned off by ohci1394's module parameter phys_dma=0.
42 42
43The alternative firewire-ohci driver in drivers/firewire uses filtered physical 43The alternative firewire-ohci driver in drivers/firewire uses filtered physical
44DMA, hence is not yet suitable for remote debugging. 44DMA by default, which is more secure but not suitable for remote debugging.
45Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
46Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
47DMA.
45 48
46Because ohci1394 depends on the PCI enumeration to be completed, an 49Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
47initialization routine which runs pretty early (long before console_init() 50completed, an initialization routine which runs pretty early has been
48which makes the printk buffer appear on the console can be called) was written. 51implemented for x86. This routine runs long before console_init() can be
52called, i.e. before the printk buffer appears on the console.
49 53
50To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu: 54To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
51Provide code for enabling DMA over FireWire early on boot) and pass the 55Remote debugging over FireWire early on boot) and pass the parameter
52parameter "ohci1394_dma=early" to the recompiled kernel on boot. 56"ohci1394_dma=early" to the recompiled kernel on boot.
53 57
54Tools 58Tools
55----- 59-----
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index bf0e3df8e7a1..4b70622a8a91 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -212,7 +212,7 @@ Who: Stephen Hemminger <shemminger@linux-foundation.org>
212--------------------------- 212---------------------------
213 213
214What: i386/x86_64 bzImage symlinks 214What: i386/x86_64 bzImage symlinks
215When: April 2008 215When: April 2010
216 216
217Why: The i386/x86_64 merge provides a symlink to the old bzImage 217Why: The i386/x86_64 merge provides a symlink to the old bzImage
218 location so not yet updated user space tools, e.g. package 218 location so not yet updated user space tools, e.g. package
@@ -318,3 +318,13 @@ Why: Not used in-tree. The current out-of-tree users used it to
318 code / infrastructure should be in the kernel and not in some 318 code / infrastructure should be in the kernel and not in some
319 out-of-tree driver. 319 out-of-tree driver.
320Who: Thomas Gleixner <tglx@linutronix.de> 320Who: Thomas Gleixner <tglx@linutronix.de>
321
322---------------------------
323
324What: /sys/o2cb symlink
325When: January 2010
326Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
327 exists as a symlink for backwards compatibility for old versions of
328 ocfs2-tools. 2 years should be sufficient time to phase in new versions
329 which know to look in /sys/fs/o2cb.
330Who: ocfs2-devel@oss.oracle.com
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index e68021c08fbd..52cd611277a3 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -66,6 +66,8 @@ mandatory-locking.txt
66 - info on the Linux implementation of Sys V mandatory file locking. 66 - info on the Linux implementation of Sys V mandatory file locking.
67ncpfs.txt 67ncpfs.txt
68 - info on Novell Netware(tm) filesystem using NCP protocol. 68 - info on Novell Netware(tm) filesystem using NCP protocol.
69nfsroot.txt
70 - short guide on setting up a diskless box with NFS root filesystem.
69ntfs.txt 71ntfs.txt
70 - info and mount options for the NTFS filesystem (Windows NT). 72 - info and mount options for the NTFS filesystem (Windows NT).
71ocfs2.txt 73ocfs2.txt
@@ -82,6 +84,10 @@ relay.txt
82 - info on relay, for efficient streaming from kernel to user space. 84 - info on relay, for efficient streaming from kernel to user space.
83romfs.txt 85romfs.txt
84 - description of the ROMFS filesystem. 86 - description of the ROMFS filesystem.
87rpc-cache.txt
88 - introduction to the caching mechanisms in the sunrpc layer.
89seq_file.txt
90 - how to use the seq_file API
85sharedsubtree.txt 91sharedsubtree.txt
86 - a description of shared subtrees for namespaces. 92 - a description of shared subtrees for namespaces.
87smbfs.txt 93smbfs.txt
diff --git a/Documentation/nfsroot.txt b/Documentation/filesystems/nfsroot.txt
index 31b329172343..31b329172343 100644
--- a/Documentation/nfsroot.txt
+++ b/Documentation/filesystems/nfsroot.txt
diff --git a/Documentation/rpc-cache.txt b/Documentation/filesystems/rpc-cache.txt
index 8a382bea6808..8a382bea6808 100644
--- a/Documentation/rpc-cache.txt
+++ b/Documentation/filesystems/rpc-cache.txt
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
new file mode 100644
index 000000000000..7fb8e6dc62bf
--- /dev/null
+++ b/Documentation/filesystems/seq_file.txt
@@ -0,0 +1,283 @@
1The seq_file interface
2
3 Copyright 2003 Jonathan Corbet <corbet@lwn.net>
4 This file is originally from the LWN.net Driver Porting series at
5 http://lwn.net/Articles/driver-porting/
6
7
8There are numerous ways for a device driver (or other kernel component) to
9provide information to the user or system administrator. One useful
10technique is the creation of virtual files, in debugfs, /proc or elsewhere.
11Virtual files can provide human-readable output that is easy to get at
12without any special utility programs; they can also make life easier for
13script writers. It is not surprising that the use of virtual files has
14grown over the years.
15
16Creating those files correctly has always been a bit of a challenge,
17however. It is not that hard to make a virtual file which returns a
18string. But life gets trickier if the output is long - anything greater
19than an application is likely to read in a single operation. Handling
20multiple reads (and seeks) requires careful attention to the reader's
21position within the virtual file - that position is, likely as not, in the
22middle of a line of output. The kernel has traditionally had a number of
23implementations that got this wrong.
24
25The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
26which are designed to make it easy for virtual file creators to get it
27right.
28
29The seq_file interface is available via <linux/seq_file.h>. There are
30three aspects to seq_file:
31
32 * An iterator interface which lets a virtual file implementation
33 step through the objects it is presenting.
34
35 * Some utility functions for formatting objects for output without
36 needing to worry about things like output buffers.
37
38 * A set of canned file_operations which implement most operations on
39 the virtual file.
40
41We'll look at the seq_file interface via an extremely simple example: a
42loadable module which creates a file called /proc/sequence. The file, when
43read, simply produces a set of increasing integer values, one per line. The
44sequence will continue until the user loses patience and finds something
45better to do. The file is seekable, in that one can do something like the
46following:
47
48 dd if=/proc/sequence of=out1 count=1
49 dd if=/proc/sequence skip=1 out=out2 count=1
50
51Then concatenate the output files out1 and out2 and get the right
52result. Yes, it is a thoroughly useless module, but the point is to show
53how the mechanism works without getting lost in other details. (Those
54wanting to see the full source for this module can find it at
55http://lwn.net/Articles/22359/).
56
57
58The iterator interface
59
60Modules implementing a virtual file with seq_file must implement a simple
61iterator object that allows stepping through the data of interest.
62Iterators must be able to move to a specific position - like the file they
63implement - but the interpretation of that position is up to the iterator
64itself. A seq_file implementation that is formatting firewall rules, for
65example, could interpret position N as the Nth rule in the chain.
66Positioning can thus be done in whatever way makes the most sense for the
67generator of the data, which need not be aware of how a position translates
68to an offset in the virtual file. The one obvious exception is that a
69position of zero should indicate the beginning of the file.
70
71The /proc/sequence iterator just uses the count of the next number it
72will output as its position.
73
74Four functions must be implemented to make the iterator work. The first,
75called start() takes a position as an argument and returns an iterator
76which will start reading at that position. For our simple sequence example,
77the start() function looks like:
78
79 static void *ct_seq_start(struct seq_file *s, loff_t *pos)
80 {
81 loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
82 if (! spos)
83 return NULL;
84 *spos = *pos;
85 return spos;
86 }
87
88The entire data structure for this iterator is a single loff_t value
89holding the current position. There is no upper bound for the sequence
90iterator, but that will not be the case for most other seq_file
91implementations; in most cases the start() function should check for a
92"past end of file" condition and return NULL if need be.
93
94For more complicated applications, the private field of the seq_file
95structure can be used. There is also a special value which can be returned
96by the start() function called SEQ_START_TOKEN; it can be used if you wish
97to instruct your show() function (described below) to print a header at the
98top of the output. SEQ_START_TOKEN should only be used if the offset is
99zero, however.
100
101The next function to implement is called, amazingly, next(); its job is to
102move the iterator forward to the next position in the sequence. The
103example module can simply increment the position by one; more useful
104modules will do what is needed to step through some data structure. The
105next() function returns a new iterator, or NULL if the sequence is
106complete. Here's the example version:
107
108 static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
109 {
110 loff_t *spos = v;
111 *pos = ++*spos;
112 return spos;
113 }
114
115The stop() function is called when iteration is complete; its job, of
116course, is to clean up. If dynamic memory is allocated for the iterator,
117stop() is the place to free it.
118
119 static void ct_seq_stop(struct seq_file *s, void *v)
120 {
121 kfree(v);
122 }
123
124Finally, the show() function should format the object currently pointed to
125by the iterator for output. It should return zero, or an error code if
126something goes wrong. The example module's show() function is:
127
128 static int ct_seq_show(struct seq_file *s, void *v)
129 {
130 loff_t *spos = v;
131 seq_printf(s, "%lld\n", (long long)*spos);
132 return 0;
133 }
134
135We will look at seq_printf() in a moment. But first, the definition of the
136seq_file iterator is finished by creating a seq_operations structure with
137the four functions we have just defined:
138
139 static const struct seq_operations ct_seq_ops = {
140 .start = ct_seq_start,
141 .next = ct_seq_next,
142 .stop = ct_seq_stop,
143 .show = ct_seq_show
144 };
145
146This structure will be needed to tie our iterator to the /proc file in
147a little bit.
148
149It's worth noting that the iterator value returned by start() and
150manipulated by the other functions is considered to be completely opaque by
151the seq_file code. It can thus be anything that is useful in stepping
152through the data to be output. Counters can be useful, but it could also be
153a direct pointer into an array or linked list. Anything goes, as long as
154the programmer is aware that things can happen between calls to the
155iterator function. However, the seq_file code (by design) will not sleep
156between the calls to start() and stop(), so holding a lock during that time
157is a reasonable thing to do. The seq_file code will also avoid taking any
158other locks while the iterator is active.
159
160
161Formatted output
162
163The seq_file code manages positioning within the output created by the
164iterator and getting it into the user's buffer. But, for that to work, that
165output must be passed to the seq_file code. Some utility functions have
166been defined which make this task easy.
167
168Most code will simply use seq_printf(), which works pretty much like
169printk(), but which requires the seq_file pointer as an argument. It is
170common to ignore the return value from seq_printf(), but a function
171producing complicated output may want to check that value and quit if
172something non-zero is returned; an error return means that the seq_file
173buffer has been filled and further output will be discarded.
174
175For straight character output, the following functions may be used:
176
177 int seq_putc(struct seq_file *m, char c);
178 int seq_puts(struct seq_file *m, const char *s);
179 int seq_escape(struct seq_file *m, const char *s, const char *esc);
180
181The first two output a single character and a string, just like one would
182expect. seq_escape() is like seq_puts(), except that any character in s
183which is in the string esc will be represented in octal form in the output.
184
185There is also a function for printing filenames:
186
187 int seq_path(struct seq_file *m, struct path *path, char *esc);
188
189Here, path indicates the file of interest, and esc is a set of characters
190which should be escaped in the output.
191
192
193Making it all work
194
195So far, we have a nice set of functions which can produce output within the
196seq_file system, but we have not yet turned them into a file that a user
197can see. Creating a file within the kernel requires, of course, the
198creation of a set of file_operations which implement the operations on that
199file. The seq_file interface provides a set of canned operations which do
200most of the work. The virtual file author still must implement the open()
201method, however, to hook everything up. The open function is often a single
202line, as in the example module:
203
204 static int ct_open(struct inode *inode, struct file *file)
205 {
206 return seq_open(file, &ct_seq_ops);
207 }
208
209Here, the call to seq_open() takes the seq_operations structure we created
210before, and gets set up to iterate through the virtual file.
211
212On a successful open, seq_open() stores the struct seq_file pointer in
213file->private_data. If you have an application where the same iterator can
214be used for more than one file, you can store an arbitrary pointer in the
215private field of the seq_file structure; that value can then be retrieved
216by the iterator functions.
217
218The other operations of interest - read(), llseek(), and release() - are
219all implemented by the seq_file code itself. So a virtual file's
220file_operations structure will look like:
221
222 static const struct file_operations ct_file_ops = {
223 .owner = THIS_MODULE,
224 .open = ct_open,
225 .read = seq_read,
226 .llseek = seq_lseek,
227 .release = seq_release
228 };
229
230There is also a seq_release_private() which passes the contents of the
231seq_file private field to kfree() before releasing the structure.
232
233The final step is the creation of the /proc file itself. In the example
234code, that is done in the initialization code in the usual way:
235
236 static int ct_init(void)
237 {
238 struct proc_dir_entry *entry;
239
240 entry = create_proc_entry("sequence", 0, NULL);
241 if (entry)
242 entry->proc_fops = &ct_file_ops;
243 return 0;
244 }
245
246 module_init(ct_init);
247
248And that is pretty much it.
249
250
251seq_list
252
253If your file will be iterating through a linked list, you may find these
254routines useful:
255
256 struct list_head *seq_list_start(struct list_head *head,
257 loff_t pos);
258 struct list_head *seq_list_start_head(struct list_head *head,
259 loff_t pos);
260 struct list_head *seq_list_next(void *v, struct list_head *head,
261 loff_t *ppos);
262
263These helpers will interpret pos as a position within the list and iterate
264accordingly. Your start() and next() functions need only invoke the
265seq_list_* helpers with a pointer to the appropriate list_head structure.
266
267
268The extra-simple version
269
270For extremely simple virtual files, there is an even easier interface. A
271module can define only the show() function, which should create all the
272output that the virtual file will contain. The file's open() method then
273calls:
274
275 int single_open(struct file *file,
276 int (*show)(struct seq_file *m, void *p),
277 void *data);
278
279When output time comes, the show() function will be called once. The data
280value given to single_open() can be found in the private field of the
281seq_file structure. When using single_open(), the programmer should use
282single_release() instead of seq_release() in the file_operations structure
283to avoid a memory leak.
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 74aeb142ae5f..0a1668ba2600 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -52,16 +52,15 @@ When mounting an XFS filesystem, the following options are accepted.
52 and also gets the setgid bit set if it is a directory itself. 52 and also gets the setgid bit set if it is a directory itself.
53 53
54 ihashsize=value 54 ihashsize=value
55 Sets the number of hash buckets available for hashing the 55 In memory inode hashes have been removed, so this option has
56 in-memory inodes of the specified mount point. If a value 56 no function as of August 2007. Option is deprecated.
57 of zero is used, the value selected by the default algorithm
58 will be displayed in /proc/mounts.
59 57
60 ikeep/noikeep 58 ikeep/noikeep
61 When inode clusters are emptied of inodes, keep them around 59 When ikeep is specified, XFS does not delete empty inode clusters
62 on the disk (ikeep) - this is the traditional XFS behaviour 60 and keeps them around on disk. ikeep is the traditional XFS
63 and is still the default for now. Using the noikeep option, 61 behaviour. When noikeep is specified, empty inode clusters
64 inode clusters are returned to the free space pool. 62 are returned to the free space pool. The default is noikeep for
63 non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
65 64
66 inode64 65 inode64
67 Indicates that XFS is allowed to create inodes at any location 66 Indicates that XFS is allowed to create inodes at any location
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index fc49b79bc1ab..2eb16100bb3f 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -170,6 +170,8 @@ Offset Proto Name Meaning
1700238/4 2.06+ cmdline_size Maximum size of the kernel command line 1700238/4 2.06+ cmdline_size Maximum size of the kernel command line
171023C/4 2.07+ hardware_subarch Hardware subarchitecture 171023C/4 2.07+ hardware_subarch Hardware subarchitecture
1720240/8 2.07+ hardware_subarch_data Subarchitecture-specific data 1720240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
1730248/4 2.08+ payload_offset Offset of kernel payload
174024C/4 2.08+ payload_length Length of kernel payload
173 175
174(1) For backwards compatibility, if the setup_sects field contains 0, the 176(1) For backwards compatibility, if the setup_sects field contains 0, the
175 real value is 4. 177 real value is 4.
@@ -512,6 +514,32 @@ Protocol: 2.07+
512 514
513 A pointer to data that is specific to hardware subarch 515 A pointer to data that is specific to hardware subarch
514 516
517Field name: payload_offset
518Type: read
519Offset/size: 0x248/4
520Protocol: 2.08+
521
522 If non-zero then this field contains the offset from the end of the
523 real-mode code to the payload.
524
525 The payload may be compressed. The format of both the compressed and
526 uncompressed data should be determined using the standard magic
527 numbers. Currently only gzip compressed ELF is used.
528
529Field name: payload_length
530Type: read
531Offset/size: 0x24c/4
532Protocol: 2.08+
533
534 The length of the payload.
535
536**** THE IMAGE CHECKSUM
537
538From boot protocol version 2.08 onwards the CRC-32 is calculated over
539the entire file using the characteristic polynomial 0x04C11DB7 and an
540initial remainder of 0xffffffff. The checksum is appended to the
541file; therefore the CRC of the file up to the limit specified in the
542syssize field of the header is always 0.
515 543
516**** THE KERNEL COMMAND LINE 544**** THE KERNEL COMMAND LINE
517 545
diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt
index 818676aad45a..486c699f4aea 100644
--- a/Documentation/ide/ide.txt
+++ b/Documentation/ide/ide.txt
@@ -71,29 +71,6 @@ This driver automatically probes for most IDE interfaces (including all PCI
71ones), for the drives/geometries attached to those interfaces, and for the IRQ 71ones), for the drives/geometries attached to those interfaces, and for the IRQ
72lines being used by the interfaces (normally 14, 15 for ide0/ide1). 72lines being used by the interfaces (normally 14, 15 for ide0/ide1).
73 73
74For special cases, interfaces may be specified using kernel "command line"
75options. For example,
76
77 ide3=0x168,0x36e,10 /* ioports 0x168-0x16f,0x36e, irq 10 */
78
79Normally the irq number need not be specified, as ide.c will probe for it:
80
81 ide3=0x168,0x36e /* ioports 0x168-0x16f,0x36e */
82
83The standard port, and irq values are these:
84
85 ide0=0x1f0,0x3f6,14
86 ide1=0x170,0x376,15
87 ide2=0x1e8,0x3ee,11
88 ide3=0x168,0x36e,10
89
90Note that the first parameter reserves 8 contiguous ioports, whereas the
91second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.
92
93In all probability the device uses these ports and IRQs if it is attached
94to the appropriate ide channel. Pass the parameter for the correct ide
95channel to the kernel, as explained above.
96
97Any number of interfaces may share a single IRQ if necessary, at a slight 74Any number of interfaces may share a single IRQ if necessary, at a slight
98performance penalty, whether on separate cards or a single VLB card. 75performance penalty, whether on separate cards or a single VLB card.
99The IDE driver automatically detects and handles this. However, this may 76The IDE driver automatically detects and handles this. However, this may
@@ -184,13 +161,6 @@ provided it is mounted with the default block size of 1024 (as above).
184Please pass on any feedback on any of this stuff to the maintainer, 161Please pass on any feedback on any of this stuff to the maintainer,
185whose address can be found in linux/MAINTAINERS. 162whose address can be found in linux/MAINTAINERS.
186 163
187Note that if BOTH hd.c and ide.c are configured into the kernel,
188hd.c will normally be allowed to control the primary IDE interface.
189This is useful for older hardware that may be incompatible with ide.c,
190and still allows newer hardware to run on the 2nd/3rd/4th IDE ports
191under control of ide.c. To have ide.c also "take over" the primary
192IDE port in this situation, use the "command line" parameter: ide0=0x1f0
193
194The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy 164The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy
195drivers can always be compiled as loadable modules, the chipset drivers 165drivers can always be compiled as loadable modules, the chipset drivers
196can only be compiled into the kernel, and the core code (ide.c) can be 166can only be compiled into the kernel, and the core code (ide.c) can be
@@ -206,7 +176,7 @@ When ide.c is used as a module, you can pass command line parameters to the
206driver using the "options=" keyword to insmod, while replacing any ',' with 176driver using the "options=" keyword to insmod, while replacing any ',' with
207';'. For example: 177';'. For example:
208 178
209 insmod ide.o options="ide0=serialize ide1=serialize ide2=0x1e8;0x3ee;11" 179 insmod ide.o options="hda=nodma hdb=nodma"
210 180
211 181
212================================================================================ 182================================================================================
@@ -247,21 +217,11 @@ Summary of ide driver parameters for kernel command line
247 As for VLB, it is safest to not specify it. 217 As for VLB, it is safest to not specify it.
248 Bigger values are safer than smaller ones. 218 Bigger values are safer than smaller ones.
249 219
250 "idex=base" : probe for an interface at the addr specified,
251 where "base" is usually 0x1f0 or 0x170
252 and "ctl" is assumed to be "base"+0x206
253
254 "idex=base,ctl" : specify both base and ctl
255
256 "idex=base,ctl,irq" : specify base, ctl, and irq number
257
258 "idex=serialize" : do not overlap operations on idex. Please note 220 "idex=serialize" : do not overlap operations on idex. Please note
259 that you will have to specify this option for 221 that you will have to specify this option for
260 both the respective primary and secondary channel 222 both the respective primary and secondary channel
261 to take effect. 223 to take effect.
262 224
263 "idex=four" : four drives on idex and ide(x^1) share same ports
264
265 "idex=reset" : reset interface after probe 225 "idex=reset" : reset interface after probe
266 226
267 "idex=ata66" : informs the interface that it has an 80c cable 227 "idex=ata66" : informs the interface that it has an 80c cable
@@ -269,8 +229,6 @@ Summary of ide driver parameters for kernel command line
269 ability to bit test for detection is currently 229 ability to bit test for detection is currently
270 unknown. 230 unknown.
271 231
272 "ide=reverse" : formerly called to pci sub-system, but now local.
273
274 "ide=doubler" : probe/support IDE doublers on Amiga 232 "ide=doubler" : probe/support IDE doublers on Amiga
275 233
276There may be more options than shown -- use the source, Luke! 234There may be more options than shown -- use the source, Luke!
@@ -290,6 +248,9 @@ Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
290kernel paremeter to enable probing for VLB version of the chipset (PCI ones 248kernel paremeter to enable probing for VLB version of the chipset (PCI ones
291are detected automatically). 249are detected automatically).
292 250
251You also need to use "probe" kernel parameter for ide-4drives driver
252(support for IDE generic chipset with four drives on one port).
253
293================================================================================ 254================================================================================
294 255
295Some Terminology 256Some Terminology
diff --git a/Documentation/ide/warm-plug-howto.txt b/Documentation/ide/warm-plug-howto.txt
new file mode 100644
index 000000000000..d5885468b072
--- /dev/null
+++ b/Documentation/ide/warm-plug-howto.txt
@@ -0,0 +1,13 @@
1
2IDE warm-plug HOWTO
3===================
4
5To warm-plug devices on a port 'idex':
6
7# echo -n "1" > /sys/class/ide_port/idex/delete_devices
8
9unplug old device(s) and plug new device(s)
10
11# echo -n "1" > /sys/class/ide_port/idex/scan
12
13done
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 32e9297ef747..256a2162503c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -763,11 +763,11 @@ and is between 256 and 4096 characters. It is defined in the file
763 Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] 763 Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
764 764
765 ide= [HW] (E)IDE subsystem 765 ide= [HW] (E)IDE subsystem
766 Format: ide=nodma or ide=doubler or ide=reverse 766 Format: ide=nodma or ide=doubler
767 See Documentation/ide/ide.txt. 767 See Documentation/ide/ide.txt.
768 768
769 ide?= [HW] (E)IDE subsystem 769 ide?= [HW] (E)IDE subsystem
770 Format: ide?=noprobe or chipset specific parameters. 770 Format: ide?=ata66 or chipset specific parameters.
771 See Documentation/ide/ide.txt. 771 See Documentation/ide/ide.txt.
772 772
773 idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed 773 idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -812,6 +812,19 @@ and is between 256 and 4096 characters. It is defined in the file
812 812
813 inttest= [IA64] 813 inttest= [IA64]
814 814
815 iommu= [x86]
816 off
817 force
818 noforce
819 biomerge
820 panic
821 nopanic
822 merge
823 nomerge
824 forcesac
825 soft
826
827
815 intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option 828 intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
816 off 829 off
817 Disable intel iommu driver. 830 Disable intel iommu driver.
@@ -844,7 +857,7 @@ and is between 256 and 4096 characters. It is defined in the file
844 arch/alpha/kernel/core_marvel.c. 857 arch/alpha/kernel/core_marvel.c.
845 858
846 ip= [IP_PNP] 859 ip= [IP_PNP]
847 See Documentation/nfsroot.txt. 860 See Documentation/filesystems/nfsroot.txt.
848 861
849 ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards 862 ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
850 See comment before ip2_setup() in 863 See comment before ip2_setup() in
@@ -928,6 +941,11 @@ and is between 256 and 4096 characters. It is defined in the file
928 kstack=N [X86-32,X86-64] Print N words from the kernel stack 941 kstack=N [X86-32,X86-64] Print N words from the kernel stack
929 in oops dumps. 942 in oops dumps.
930 943
944 kgdboc= [HW] kgdb over consoles.
945 Requires a tty driver that supports console polling.
946 (only serial suported for now)
947 Format: <serial_device>[,baud]
948
931 l2cr= [PPC] 949 l2cr= [PPC]
932 950
933 lapic [X86-32,APIC] Enable the local APIC even if BIOS 951 lapic [X86-32,APIC] Enable the local APIC even if BIOS
@@ -1134,6 +1152,11 @@ and is between 256 and 4096 characters. It is defined in the file
1134 or 1152 or
1135 memmap=0x10000$0x18690000 1153 memmap=0x10000$0x18690000
1136 1154
1155 memtest= [KNL,X86_64] Enable memtest
1156 Format: <integer>
1157 range: 0,4 : pattern number
1158 default : 0 <disable>
1159
1137 meye.*= [HW] Set MotionEye Camera parameters 1160 meye.*= [HW] Set MotionEye Camera parameters
1138 See Documentation/video4linux/meye.txt. 1161 See Documentation/video4linux/meye.txt.
1139 1162
@@ -1198,10 +1221,10 @@ and is between 256 and 4096 characters. It is defined in the file
1198 file if at all. 1221 file if at all.
1199 1222
1200 nfsaddrs= [NFS] 1223 nfsaddrs= [NFS]
1201 See Documentation/nfsroot.txt. 1224 See Documentation/filesystems/nfsroot.txt.
1202 1225
1203 nfsroot= [NFS] nfs root filesystem for disk-less boxes. 1226 nfsroot= [NFS] nfs root filesystem for disk-less boxes.
1204 See Documentation/nfsroot.txt. 1227 See Documentation/filesystems/nfsroot.txt.
1205 1228
1206 nfs.callback_tcpport= 1229 nfs.callback_tcpport=
1207 [NFS] set the TCP port on which the NFSv4 callback 1230 [NFS] set the TCP port on which the NFSv4 callback
@@ -1339,6 +1362,10 @@ and is between 256 and 4096 characters. It is defined in the file
1339 1362
1340 nowb [ARM] 1363 nowb [ARM]
1341 1364
1365 nptcg= [IA64] Override max number of concurrent global TLB
1366 purges which is reported from either PAL_VM_SUMMARY or
1367 SAL PALO.
1368
1342 numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. 1369 numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
1343 one of ['zone', 'node', 'default'] can be specified 1370 one of ['zone', 'node', 'default'] can be specified
1344 This can be set from sysctl after boot. 1371 This can be set from sysctl after boot.
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index f1b2de170929..641d2afacffa 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -281,10 +281,10 @@ solution for a couple of reasons:
281 sa_family_t can_family; 281 sa_family_t can_family;
282 int can_ifindex; 282 int can_ifindex;
283 union { 283 union {
284 struct { canid_t rx_id, tx_id; } tp16; 284 /* transport protocol class address info (e.g. ISOTP) */
285 struct { canid_t rx_id, tx_id; } tp20; 285 struct { canid_t rx_id, tx_id; } tp;
286 struct { canid_t rx_id, tx_id; } mcnet; 286
287 struct { canid_t rx_id, tx_id; } isotp; 287 /* reserved for future CAN protocols address information */
288 } can_addr; 288 } can_addr;
289 }; 289 };
290 290
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index 0eb7c58916de..e05420973698 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -115,6 +115,27 @@ Return Value: Handle for generated debug area
115Description: Allocates memory for a debug log 115Description: Allocates memory for a debug log
116 Must not be called within an interrupt handler 116 Must not be called within an interrupt handler
117 117
118----------------------------------------------------------------------------
119debug_info_t *debug_register_mode(char *name, int pages, int nr_areas,
120 int buf_size, mode_t mode, uid_t uid,
121 gid_t gid);
122
123Parameter: name: Name of debug log (e.g. used for debugfs entry)
124 pages: Number of pages, which will be allocated per area
125 nr_areas: Number of debug areas
126 buf_size: Size of data area in each debug entry
127 mode: File mode for debugfs files. E.g. S_IRWXUGO
128 uid: User ID for debugfs files. Currently only 0 is
129 supported.
130 gid: Group ID for debugfs files. Currently only 0 is
131 supported.
132
133Return Value: Handle for generated debug area
134 NULL if register failed
135
136Description: Allocates memory for a debug log
137 Must not be called within an interrupt handler
138
118--------------------------------------------------------------------------- 139---------------------------------------------------------------------------
119void debug_unregister (debug_info_t * id); 140void debug_unregister (debug_info_t * id);
120 141
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index b5f5ca069b2d..fc234d093fbf 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -12,5 +12,7 @@ sched-domains.txt
12 - information on scheduling domains. 12 - information on scheduling domains.
13sched-nice-design.txt 13sched-nice-design.txt
14 - How and why the scheduler's nice levels are implemented. 14 - How and why the scheduler's nice levels are implemented.
15sched-rt-group.txt
16 - real-time group scheduling.
15sched-stats.txt 17sched-stats.txt
16 - information on schedstats (Linux Scheduler Statistics). 18 - information on schedstats (Linux Scheduler Statistics).
diff --git a/Documentation/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
index 1c6332f4543c..1c6332f4543c 100644
--- a/Documentation/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 8861e47e5a2d..6d5f18143c50 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -116,6 +116,13 @@ low order bit. So when a chip's timing diagram shows the clock
116starting low (CPOL=0) and data stabilized for sampling during the 116starting low (CPOL=0) and data stabilized for sampling during the
117trailing clock edge (CPHA=1), that's SPI mode 1. 117trailing clock edge (CPHA=1), that's SPI mode 1.
118 118
119Note that the clock mode is relevant as soon as the chipselect goes
120active. So the master must set the clock to inactive before selecting
121a slave, and the slave can tell the chosen polarity by sampling the
122clock level when its select line goes active. That's why many devices
123support for example both modes 0 and 3: they don't care about polarity,
124and alway clock data in/out on rising clock edges.
125
119 126
120How do these driver programming interfaces work? 127How do these driver programming interfaces work?
121------------------------------------------------ 128------------------------------------------------
@@ -379,8 +386,14 @@ any more such messages.
379 + when bidirectional reads and writes start ... by how its 386 + when bidirectional reads and writes start ... by how its
380 sequence of spi_transfer requests is arranged; 387 sequence of spi_transfer requests is arranged;
381 388
389 + which I/O buffers are used ... each spi_transfer wraps a
390 buffer for each transfer direction, supporting full duplex
391 (two pointers, maybe the same one in both cases) and half
392 duplex (one pointer is NULL) transfers;
393
382 + optionally defining short delays after transfers ... using 394 + optionally defining short delays after transfers ... using
383 the spi_transfer.delay_usecs setting; 395 the spi_transfer.delay_usecs setting (this delay can be the
396 only protocol effect, if the buffer length is zero);
384 397
385 + whether the chipselect becomes inactive after a transfer and 398 + whether the chipselect becomes inactive after a transfer and
386 any delay ... by using the spi_transfer.cs_change flag; 399 any delay ... by using the spi_transfer.cs_change flag;
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 471e75389778..619699dde593 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -5,6 +5,28 @@ Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
5__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static 5__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
6initialization. 6initialization.
7 7
8Most of the time, you can simply turn:
9
10 static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
11
12into:
13
14 static DEFINE_SPINLOCK(xxx_lock);
15
16Static structure member variables go from:
17
18 struct foo bar {
19 .lock = SPIN_LOCK_UNLOCKED;
20 };
21
22to:
23
24 struct foo bar {
25 .lock = __SPIN_LOCK_UNLOCKED(bar.lock);
26 };
27
28Declaration of static rw_locks undergo a similar transformation.
29
8Dynamic initialization, when necessary, may be performed as 30Dynamic initialization, when necessary, may be performed as
9demonstrated below. 31demonstrated below.
10 32
diff --git a/Documentation/hrtimers/highres.txt b/Documentation/timers/highres.txt
index ce0e9a91e157..a73ecf5b4bdb 100644
--- a/Documentation/hrtimers/highres.txt
+++ b/Documentation/timers/highres.txt
@@ -98,7 +98,7 @@ System-level global event devices are used for the Linux periodic tick. Per-CPU
98event devices are used to provide local CPU functionality such as process 98event devices are used to provide local CPU functionality such as process
99accounting, profiling, and high resolution timers. 99accounting, profiling, and high resolution timers.
100 100
101The management layer assignes one or more of the folliwing functions to a clock 101The management layer assigns one or more of the following functions to a clock
102event device: 102event device:
103 - system global periodic tick (jiffies update) 103 - system global periodic tick (jiffies update)
104 - cpu local update_process_times 104 - cpu local update_process_times
diff --git a/Documentation/hrtimers/hrtimers.txt b/Documentation/timers/hrtimers.txt
index ce31f65e12e7..ce31f65e12e7 100644
--- a/Documentation/hrtimers/hrtimers.txt
+++ b/Documentation/timers/hrtimers.txt
diff --git a/Documentation/hrtimer/timer_stats.txt b/Documentation/timers/timer_stats.txt
index 20d368c59814..20d368c59814 100644
--- a/Documentation/hrtimer/timer_stats.txt
+++ b/Documentation/timers/timer_stats.txt
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index f962d01bea2a..3102b81bef88 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As
88these surplus hugepages go out of use, they are freed back to the buddy 88these surplus hugepages go out of use, they are freed back to the buddy
89allocator. 89allocator.
90 90
91Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect 91Caveat: Shrinking the pool via nr_hugepages such that it becomes less
92will allow the number of surplus huge pages to exceed the overcommit 92than the number of hugepages in use will convert the balance to surplus
93value, as the pool hugepages (which must have been in use for a surplus 93huge pages even if it would exceed the overcommit value. As long as
94hugepages to be allocated) will become surplus hugepages. As long as
95this condition holds, however, no more surplus huge pages will be 94this condition holds, however, no more surplus huge pages will be
96allowed on the system until one of the two sysctls are increased 95allowed on the system until one of the two sysctls are increased
97sufficiently, or the surplus huge pages go out of use and are freed. 96sufficiently, or the surplus huge pages go out of use and are freed.
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
new file mode 100644
index 000000000000..17965f927c15
--- /dev/null
+++ b/Documentation/x86/pat.txt
@@ -0,0 +1,100 @@
1
2PAT (Page Attribute Table)
3
4x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
5page level granularity. PAT is complementary to the MTRR settings which allows
6for setting of memory types over physical address ranges. However, PAT is
7more flexible than MTRR due to its capability to set attributes at page level
8and also due to the fact that there are no hardware limitations on number of
9such attribute settings allowed. Added flexibility comes with guidelines for
10not having memory type aliasing for the same physical memory with multiple
11virtual addresses.
12
13PAT allows for different types of memory attributes. The most commonly used
14ones that will be supported at this time are Write-back, Uncached,
15Write-combined and Uncached Minus.
16
17There are many different APIs in the kernel that allows setting of memory
18attributes at the page level. In order to avoid aliasing, these interfaces
19should be used thoughtfully. Below is a table of interfaces available,
20their intended usage and their memory attribute relationships. Internally,
21these APIs use a reserve_memtype()/free_memtype() interface on the physical
22address range to avoid any aliasing.
23
24
25-------------------------------------------------------------------
26API | RAM | ACPI,... | Reserved/Holes |
27-----------------------|----------|------------|------------------|
28 | | | |
29ioremap | -- | UC | UC |
30 | | | |
31ioremap_cache | -- | WB | WB |
32 | | | |
33ioremap_nocache | -- | UC | UC |
34 | | | |
35ioremap_wc | -- | -- | WC |
36 | | | |
37set_memory_uc | UC | -- | -- |
38 set_memory_wb | | | |
39 | | | |
40set_memory_wc | WC | -- | -- |
41 set_memory_wb | | | |
42 | | | |
43pci sysfs resource | -- | -- | UC |
44 | | | |
45pci sysfs resource_wc | -- | -- | WC |
46 is IORESOURCE_PREFETCH| | | |
47 | | | |
48pci proc | -- | -- | UC |
49 !PCIIOC_WRITE_COMBINE | | | |
50 | | | |
51pci proc | -- | -- | WC |
52 PCIIOC_WRITE_COMBINE | | | |
53 | | | |
54/dev/mem | -- | UC | UC |
55 read-write | | | |
56 | | | |
57/dev/mem | -- | UC | UC |
58 mmap SYNC flag | | | |
59 | | | |
60/dev/mem | -- | WB/WC/UC | WB/WC/UC |
61 mmap !SYNC flag | |(from exist-| (from exist- |
62 and | | ing alias)| ing alias) |
63 any alias to this area| | | |
64 | | | |
65/dev/mem | -- | WB | WB |
66 mmap !SYNC flag | | | |
67 no alias to this area | | | |
68 and | | | |
69 MTRR says WB | | | |
70 | | | |
71/dev/mem | -- | -- | UC_MINUS |
72 mmap !SYNC flag | | | |
73 no alias to this area | | | |
74 and | | | |
75 MTRR says !WB | | | |
76 | | | |
77-------------------------------------------------------------------
78
79Notes:
80
81-- in the above table mean "Not suggested usage for the API". Some of the --'s
82are strictly enforced by the kernel. Some others are not really enforced
83today, but may be enforced in future.
84
85For ioremap and pci access through /sys or /proc - The actual type returned
86can be more restrictive, in case of any existing aliasing for that address.
87For example: If there is an existing uncached mapping, a new ioremap_wc can
88return uncached mapping in place of write-combine requested.
89
90set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will
91first make a region uc or wc and switch it back to wb after use.
92
93Over time writes to /proc/mtrr will be deprecated in favor of using PAT based
94interfaces. Users writing to /proc/mtrr are suggested to use above interfaces.
95
96Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access
97types.
98
99Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
100
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index 34abae4e9442..b0c7b6c4abda 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -307,3 +307,8 @@ Debugging
307 stuck (default) 307 stuck (default)
308 308
309Miscellaneous 309Miscellaneous
310
311 nogbpages
312 Do not use GB pages for kernel direct mappings.
313 gbpages
314 Use GB pages for kernel direct mappings.
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-19 08:28:40 -0500