mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 02:32:09 -04:00
fix typos "wich" -> "which"
Signed-off-by: Uwe Zeisberger <[email protected]> Signed-off-by: Adrian Bunk <[email protected]>
This commit is contained in:
parent
c690a72253
commit
c30fe7f731
10 changed files with 17 additions and 16 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue