aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@g5.osdl.org>2006-03-25 11:41:09 -0500
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-25 11:41:09 -0500
commit1e8c573933fd7975679766850252ad08667e5ca4 (patch)
tree9600d0c7ee5ea8925f3c4dc30680c819e0363805 /Documentation
parentd71eecf3b8e893757cc3dec560c96a32ac090890 (diff)
parent232443e2c90cc2930624dec89df327615b002c55 (diff)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (21 commits) BUG_ON() Conversion in drivers/video/ BUG_ON() Conversion in drivers/parisc/ BUG_ON() Conversion in drivers/block/ BUG_ON() Conversion in sound/sparc/cs4231.c BUG_ON() Conversion in drivers/s390/block/dasd.c BUG_ON() Conversion in lib/swiotlb.c BUG_ON() Conversion in kernel/cpu.c BUG_ON() Conversion in ipc/msg.c BUG_ON() Conversion in block/elevator.c BUG_ON() Conversion in fs/coda/ BUG_ON() Conversion in fs/binfmt_elf_fdpic.c BUG_ON() Conversion in input/serio/hil_mlc.c BUG_ON() Conversion in md/dm-hw-handler.c BUG_ON() Conversion in md/bitmap.c The comment describing how MS_ASYNC works in msync.c is confusing rcu: undeclared variable used in documentation fix typos "wich" -> "which" typo patch for fs/ufs/super.c Fix simple typos tabify drivers/char/Makefile ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/RCU/whatisRCU.txt4
-rw-r--r--Documentation/arm/Booting2
-rw-r--r--Documentation/arm/README2
-rw-r--r--Documentation/arm/Setup2
-rw-r--r--Documentation/filesystems/proc.txt6
-rw-r--r--Documentation/networking/packet_mmap.txt10
6 files changed, 13 insertions, 13 deletions
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 5ed85af88789..b4ea51ad3610 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -360,7 +360,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt.
360 struct foo *new_fp; 360 struct foo *new_fp;
361 struct foo *old_fp; 361 struct foo *old_fp;
362 362
363 new_fp = kmalloc(sizeof(*fp), GFP_KERNEL); 363 new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
364 spin_lock(&foo_mutex); 364 spin_lock(&foo_mutex);
365 old_fp = gbl_foo; 365 old_fp = gbl_foo;
366 *new_fp = *old_fp; 366 *new_fp = *old_fp;
@@ -461,7 +461,7 @@ The foo_update_a() function might then be written as follows:
461 struct foo *new_fp; 461 struct foo *new_fp;
462 struct foo *old_fp; 462 struct foo *old_fp;
463 463
464 new_fp = kmalloc(sizeof(*fp), GFP_KERNEL); 464 new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
465 spin_lock(&foo_mutex); 465 spin_lock(&foo_mutex);
466 old_fp = gbl_foo; 466 old_fp = gbl_foo;
467 *new_fp = *old_fp; 467 *new_fp = *old_fp;
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index fad566bb02fc..76850295af8f 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -118,7 +118,7 @@ to store page tables. The recommended placement is 32KiB into RAM.
118 118
119In either case, the following conditions must be met: 119In either case, the following conditions must be met:
120 120
121- Quiesce all DMA capable devicess so that memory does not get 121- Quiesce all DMA capable devices so that memory does not get
122 corrupted by bogus network packets or disk data. This will save 122 corrupted by bogus network packets or disk data. This will save
123 you many hours of debug. 123 you many hours of debug.
124 124
diff --git a/Documentation/arm/README b/Documentation/arm/README
index 5ed6f3530b86..9b9c8226fdc4 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README
@@ -89,7 +89,7 @@ Modules
89 Although modularisation is supported (and required for the FP emulator), 89 Although modularisation is supported (and required for the FP emulator),
90 each module on an ARM2/ARM250/ARM3 machine when is loaded will take 90 each module on an ARM2/ARM250/ARM3 machine when is loaded will take
91 memory up to the next 32k boundary due to the size of the pages. 91 memory up to the next 32k boundary due to the size of the pages.
92 Therefore, modularisation on these machines really worth it? 92 Therefore, is modularisation on these machines really worth it?
93 93
94 However, ARM6 and up machines allow modules to take multiples of 4k, and 94 However, ARM6 and up machines allow modules to take multiples of 4k, and
95 as such Acorn RiscPCs and other architectures using these processors can 95 as such Acorn RiscPCs and other architectures using these processors can
diff --git a/Documentation/arm/Setup b/Documentation/arm/Setup
index 0abd0720d7ed..0cb1e64bde80 100644
--- a/Documentation/arm/Setup
+++ b/Documentation/arm/Setup
@@ -58,7 +58,7 @@ below:
58 video_y 58 video_y
59 59
60 This describes the character position of cursor on VGA console, and 60 This describes the character position of cursor on VGA console, and
61 is otherwise unused. (should not used for other console types, and 61 is otherwise unused. (should not be used for other console types, and
62 should not be used for other purposes). 62 should not be used for other purposes).
63 63
64 memc_control_reg 64 memc_control_reg
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 944cf109a6f5..99902ae6804e 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
121.............................................................................. 121..............................................................................
122 File Content 122 File Content
123 cmdline Command line arguments 123 cmdline Command line arguments
124 cpu Current and last cpu in wich it was executed (2.4)(smp) 124 cpu Current and last cpu in which it was executed (2.4)(smp)
125 cwd Link to the current working directory 125 cwd Link to the current working directory
126 environ Values of environment variables 126 environ Values of environment variables
127 exe Link to the executable of this process 127 exe Link to the executable of this process
@@ -309,13 +309,13 @@ is the same by default:
309 > cat /proc/irq/0/smp_affinity 309 > cat /proc/irq/0/smp_affinity
310 ffffffff 310 ffffffff
311 311
312It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can 312It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can
313set it by doing: 313set it by doing:
314 314
315 > echo 1 > /proc/irq/prof_cpu_mask 315 > echo 1 > /proc/irq/prof_cpu_mask
316 316
317This means that only the first CPU will handle the IRQ, but you can also echo 5 317This means that only the first CPU will handle the IRQ, but you can also echo 5
318wich means that only the first and fourth CPU can handle the IRQ. 318which means that only the first and fourth CPU can handle the IRQ.
319 319
320The way IRQs are routed is handled by the IO-APIC, and it's Round Robin 320The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
321between all the CPUs which are allowed to handle it. As usual the kernel has 321between all the CPUs which are allowed to handle it. As usual the kernel has
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 8d4cf78258e4..4fc8e9874320 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -40,7 +40,7 @@ network interface card supports some sort of interrupt load mitigation or
40+ How to use CONFIG_PACKET_MMAP 40+ How to use CONFIG_PACKET_MMAP
41-------------------------------------------------------------------------------- 41--------------------------------------------------------------------------------
42 42
43From the user standpoint, you should use the higher level libpcap library, wich 43From the user standpoint, you should use the higher level libpcap library, which
44is a de facto standard, portable across nearly all operating systems 44is a de facto standard, portable across nearly all operating systems
45including Win32. 45including Win32.
46 46
@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated.
217 217
218kmalloc allocates any number of bytes of phisically contiguous memory from 218kmalloc allocates any number of bytes of phisically contiguous memory from
219a pool of pre-determined sizes. This pool of memory is mantained by the slab 219a pool of pre-determined sizes. This pool of memory is mantained by the slab
220allocator wich is at the end the responsible for doing the allocation and 220allocator which is at the end the responsible for doing the allocation and
221hence wich imposes the maximum memory that kmalloc can allocate. 221hence which imposes the maximum memory that kmalloc can allocate.
222 222
223In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The 223In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
224predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" 224predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
@@ -254,7 +254,7 @@ and, the number of frames be
254 254
255 <block number> * <block size> / <frame size> 255 <block number> * <block size> / <frame size>
256 256
257Suposse the following parameters, wich apply for 2.6 kernel and an 257Suposse the following parameters, which apply for 2.6 kernel and an
258i386 architecture: 258i386 architecture:
259 259
260 <size-max> = 131072 bytes 260 <size-max> = 131072 bytes
@@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
360 statistics where checked with getsockopt() and 360 statistics where checked with getsockopt() and
361 the PACKET_STATISTICS option. 361 the PACKET_STATISTICS option.
362 362
363TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich 363TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
364 it's checksum will be done in hardware. So while 364 it's checksum will be done in hardware. So while
365 reading the packet we should not try to check the 365 reading the packet we should not try to check the
366 checksum. 366 checksum.