diff options
author | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-25 11:41:09 -0500 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-25 11:41:09 -0500 |
commit | 1e8c573933fd7975679766850252ad08667e5ca4 (patch) | |
tree | 9600d0c7ee5ea8925f3c4dc30680c819e0363805 /Documentation | |
parent | d71eecf3b8e893757cc3dec560c96a32ac090890 (diff) | |
parent | 232443e2c90cc2930624dec89df327615b002c55 (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.txt | 4 | ||||
-rw-r--r-- | Documentation/arm/Booting | 2 | ||||
-rw-r--r-- | Documentation/arm/README | 2 | ||||
-rw-r--r-- | Documentation/arm/Setup | 2 | ||||
-rw-r--r-- | Documentation/filesystems/proc.txt | 6 | ||||
-rw-r--r-- | Documentation/networking/packet_mmap.txt | 10 |
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 | ||
119 | In either case, the following conditions must be met: | 119 | In 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 | ||
312 | It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can | 312 | It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can |
313 | set it by doing: | 313 | set it by doing: |
314 | 314 | ||
315 | > echo 1 > /proc/irq/prof_cpu_mask | 315 | > echo 1 > /proc/irq/prof_cpu_mask |
316 | 316 | ||
317 | This means that only the first CPU will handle the IRQ, but you can also echo 5 | 317 | This means that only the first CPU will handle the IRQ, but you can also echo 5 |
318 | wich means that only the first and fourth CPU can handle the IRQ. | 318 | which means that only the first and fourth CPU can handle the IRQ. |
319 | 319 | ||
320 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin | 320 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin |
321 | between all the CPUs which are allowed to handle it. As usual the kernel has | 321 | between 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 | ||
43 | From the user standpoint, you should use the higher level libpcap library, wich | 43 | From the user standpoint, you should use the higher level libpcap library, which |
44 | is a de facto standard, portable across nearly all operating systems | 44 | is a de facto standard, portable across nearly all operating systems |
45 | including Win32. | 45 | including Win32. |
46 | 46 | ||
@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated. | |||
217 | 217 | ||
218 | kmalloc allocates any number of bytes of phisically contiguous memory from | 218 | kmalloc allocates any number of bytes of phisically contiguous memory from |
219 | a pool of pre-determined sizes. This pool of memory is mantained by the slab | 219 | a pool of pre-determined sizes. This pool of memory is mantained by the slab |
220 | allocator wich is at the end the responsible for doing the allocation and | 220 | allocator which is at the end the responsible for doing the allocation and |
221 | hence wich imposes the maximum memory that kmalloc can allocate. | 221 | hence which imposes the maximum memory that kmalloc can allocate. |
222 | 222 | ||
223 | In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The | 223 | In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The |
224 | predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" | 224 | predetermined 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 | ||
257 | Suposse the following parameters, wich apply for 2.6 kernel and an | 257 | Suposse the following parameters, which apply for 2.6 kernel and an |
258 | i386 architecture: | 258 | i386 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 | ||
363 | TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich | 363 | TP_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. |