mirror of
https://github.com/torvalds/linux.git
synced 2024-11-22 12:11:40 +00:00
fix typos "wich" -> "which"
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
parent
c690a72253
commit
c30fe7f731
@ -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.
|
||||
|
@ -256,7 +256,8 @@ config ACPI_CUSTOM_DSDT_FILE
|
||||
depends on ACPI_CUSTOM_DSDT
|
||||
default ""
|
||||
help
|
||||
Enter the full path name to the file wich includes the AmlCode declaration.
|
||||
Enter the full path name to the file which includes the AmlCode
|
||||
declaration.
|
||||
|
||||
config ACPI_BLACKLIST_YEAR
|
||||
int "Disable ACPI for systems before Jan 1st this year" if X86_32
|
||||
|
@ -7,7 +7,7 @@
|
||||
*
|
||||
* stuff needed to support the Linux X.25 PLP code on top of devices that
|
||||
* can provide a lab_b service using the concap_proto mechanism.
|
||||
* This module supports a network interface wich provides lapb_sematics
|
||||
* This module supports a network interface which provides lapb_sematics
|
||||
* -- as defined in Documentation/networking/x25-iface.txt -- to
|
||||
* the upper layer and assumes that the lower layer provides a reliable
|
||||
* data link service by means of the concap_device_ops callbacks.
|
||||
|
@ -40,7 +40,7 @@
|
||||
* and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
|
||||
* so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
|
||||
* fpr the console code : without this 1:1 mapping, at early boot time, when we
|
||||
* are parsing the kernel args console=ttyPSC?, we wouldn't know wich PSC it
|
||||
* are parsing the kernel args console=ttyPSC?, we wouldn't know which PSC it
|
||||
* will be mapped to.
|
||||
*/
|
||||
|
||||
|
@ -102,7 +102,7 @@ static struct usb_driver option_driver = {
|
||||
.no_dynamic_id = 1,
|
||||
};
|
||||
|
||||
/* The card has three separate interfaces, wich the serial driver
|
||||
/* The card has three separate interfaces, which the serial driver
|
||||
* recognizes separately, thus num_port=1.
|
||||
*/
|
||||
static struct usb_serial_driver option_3port_device = {
|
||||
|
@ -32,7 +32,7 @@
|
||||
|
||||
-TODO: at one time or another test that the mode is acceptable by the monitor
|
||||
-ASK: Can I choose different ordering for the color bitfields (rgba argb ...)
|
||||
wich one should i use ? is there any preferred one ? It seems ARGB is
|
||||
which one should i use ? is there any preferred one ? It seems ARGB is
|
||||
the one ...
|
||||
-TODO: in set_var check the validity of timings (hsync vsync)...
|
||||
-TODO: check and recheck the use of sst_wait_idle : we don't flush the fifo via
|
||||
|
@ -98,7 +98,7 @@ static void matrox_w1_write_ddc_bit(void *, u8);
|
||||
*
|
||||
* Using tristate pins, since i can't find any open-drain pin in whole motherboard.
|
||||
* Unfortunately we can't connect to Intel's 82801xx IO controller
|
||||
* since we don't know motherboard schema, wich has pretty unused(may be not) GPIO.
|
||||
* since we don't know motherboard schema, which has pretty unused(may be not) GPIO.
|
||||
*
|
||||
* I've heard that PIIX also has open drain pin.
|
||||
*
|
||||
|
@ -118,7 +118,7 @@ befs_fblock2brun(struct super_block *sb, befs_data_stream * data,
|
||||
* befs_read_lsmylink - read long symlink from datastream.
|
||||
* @sb: Filesystem superblock
|
||||
* @ds: Datastrem to read from
|
||||
* @buf: Buffer in wich to place long symlink data
|
||||
* @buf: Buffer in which to place long symlink data
|
||||
* @len: Length of the long symlink in bytes
|
||||
*
|
||||
* Returns the number of bytes read
|
||||
|
@ -4,7 +4,7 @@
|
||||
#
|
||||
# Stage one of module building created the following:
|
||||
# a) The individual .o files used for the module
|
||||
# b) A <module>.o file wich is the .o files above linked together
|
||||
# b) A <module>.o file which is the .o files above linked together
|
||||
# c) A <module>.mod file in $(MODVERDIR)/, listing the name of the
|
||||
# the preliminary <module>.o file, plus all .o files
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user