aboutsummaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@g5.osdl.org>2006-03-25 08:41:09 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-25 08:41:09 -0800
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 5ed85af8878..b4ea51ad361 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.
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
+ new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = gbl_foo;
*new_fp = *old_fp;
@@ -461,7 +461,7 @@ The foo_update_a() function might then be written as follows:
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
+ new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = gbl_foo;
*new_fp = *old_fp;
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index fad566bb02f..76850295af8 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -118,7 +118,7 @@ to store page tables. The recommended placement is 32KiB into RAM.
In either case, the following conditions must be met:
-- Quiesce all DMA capable devicess so that memory does not get
+- Quiesce all DMA capable devices so that memory does not get
corrupted by bogus network packets or disk data. This will save
you many hours of debug.
diff --git a/Documentation/arm/README b/Documentation/arm/README
index 5ed6f3530b8..9b9c8226fdc 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README
@@ -89,7 +89,7 @@ Modules
Although modularisation is supported (and required for the FP emulator),
each module on an ARM2/ARM250/ARM3 machine when is loaded will take
memory up to the next 32k boundary due to the size of the pages.
- Therefore, modularisation on these machines really worth it?
+ Therefore, is modularisation on these machines really worth it?
However, ARM6 and up machines allow modules to take multiples of 4k, and
as such Acorn RiscPCs and other architectures using these processors can
diff --git a/Documentation/arm/Setup b/Documentation/arm/Setup
index 0abd0720d7e..0cb1e64bde8 100644
--- a/Documentation/arm/Setup
+++ b/Documentation/arm/Setup
@@ -58,7 +58,7 @@ below:
video_y
This describes the character position of cursor on VGA console, and
- is otherwise unused. (should not used for other console types, and
+ is otherwise unused. (should not be used for other console types, and
should not be used for other purposes).
memc_control_reg
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 944cf109a6f..99902ae6804 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
..............................................................................
File Content
cmdline Command line arguments
- cpu Current and last cpu in wich it was executed (2.4)(smp)
+ cpu Current and last cpu in which it was executed (2.4)(smp)
cwd Link to the current working directory
environ Values of environment variables
exe Link to the executable of this process
@@ -309,13 +309,13 @@ is the same by default:
> cat /proc/irq/0/smp_affinity
ffffffff
-It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can
+It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can
set it by doing:
> echo 1 > /proc/irq/prof_cpu_mask
This means that only the first CPU will handle the IRQ, but you can also echo 5
-wich means that only the first and fourth CPU can handle the IRQ.
+which means that only the first and fourth CPU can handle the IRQ.
The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
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 8d4cf78258e..4fc8e987432 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
+ How to use CONFIG_PACKET_MMAP
--------------------------------------------------------------------------------
-From the user standpoint, you should use the higher level libpcap library, wich
+From the user standpoint, you should use the higher level libpcap library, which
is a de facto standard, portable across nearly all operating systems
including Win32.
@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated.
kmalloc allocates any number of bytes of phisically contiguous memory from
a pool of pre-determined sizes. This pool of memory is mantained by the slab
-allocator wich is at the end the responsible for doing the allocation and
-hence wich imposes the maximum memory that kmalloc can allocate.
+allocator which is at the end the responsible for doing the allocation and
+hence which imposes the maximum memory that kmalloc can allocate.
In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
@@ -254,7 +254,7 @@ and, the number of frames be
<block number> * <block size> / <frame size>
-Suposse the following parameters, wich apply for 2.6 kernel and an
+Suposse the following parameters, which apply for 2.6 kernel and an
i386 architecture:
<size-max> = 131072 bytes
@@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
statistics where checked with getsockopt() and
the PACKET_STATISTICS option.
-TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich
+TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
it's checksum will be done in hardware. So while
reading the packet we should not try to check the
checksum.