提交 c30fe7f7 编写于 作者: U Uwe Zeisberger 提交者: Adrian Bunk

fix typos "wich" -> "which"

Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
上级 c690a722
...@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc ...@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
.............................................................................. ..............................................................................
File Content File Content
cmdline Command line arguments 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 cwd Link to the current working directory
environ Values of environment variables environ Values of environment variables
exe Link to the executable of this process exe Link to the executable of this process
...@@ -309,13 +309,13 @@ is the same by default: ...@@ -309,13 +309,13 @@ is the same by default:
> cat /proc/irq/0/smp_affinity > cat /proc/irq/0/smp_affinity
ffffffff 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: set it by doing:
> echo 1 > /proc/irq/prof_cpu_mask > echo 1 > /proc/irq/prof_cpu_mask
This means that only the first CPU will handle the IRQ, but you can also echo 5 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 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 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 ...@@ -40,7 +40,7 @@ network interface card supports some sort of interrupt load mitigation or
+ How to use CONFIG_PACKET_MMAP + 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 is a de facto standard, portable across nearly all operating systems
including Win32. including Win32.
...@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated. ...@@ -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 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 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 allocator which is at the end the responsible for doing the allocation and
hence wich imposes the maximum memory that kmalloc can allocate. 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 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>" predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
...@@ -254,7 +254,7 @@ and, the number of frames be ...@@ -254,7 +254,7 @@ and, the number of frames be
<block number> * <block size> / <frame size> <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: i386 architecture:
<size-max> = 131072 bytes <size-max> = 131072 bytes
...@@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time ...@@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
statistics where checked with getsockopt() and statistics where checked with getsockopt() and
the PACKET_STATISTICS option. 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 it's checksum will be done in hardware. So while
reading the packet we should not try to check the reading the packet we should not try to check the
checksum. checksum.
......
...@@ -256,7 +256,8 @@ config ACPI_CUSTOM_DSDT_FILE ...@@ -256,7 +256,8 @@ config ACPI_CUSTOM_DSDT_FILE
depends on ACPI_CUSTOM_DSDT depends on ACPI_CUSTOM_DSDT
default "" default ""
help 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 config ACPI_BLACKLIST_YEAR
int "Disable ACPI for systems before Jan 1st this year" if X86_32 int "Disable ACPI for systems before Jan 1st this year" if X86_32
......
...@@ -7,7 +7,7 @@ ...@@ -7,7 +7,7 @@
* *
* stuff needed to support the Linux X.25 PLP code on top of devices that * 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. * 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 * -- as defined in Documentation/networking/x25-iface.txt -- to
* the upper layer and assumes that the lower layer provides a reliable * the upper layer and assumes that the lower layer provides a reliable
* data link service by means of the concap_device_ops callbacks. * data link service by means of the concap_device_ops callbacks.
......
...@@ -40,7 +40,7 @@ ...@@ -40,7 +40,7 @@
* and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and * 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 * 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 * 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. * will be mapped to.
*/ */
......
...@@ -102,7 +102,7 @@ static struct usb_driver option_driver = { ...@@ -102,7 +102,7 @@ static struct usb_driver option_driver = {
.no_dynamic_id = 1, .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. * recognizes separately, thus num_port=1.
*/ */
static struct usb_serial_driver option_3port_device = { static struct usb_serial_driver option_3port_device = {
......
...@@ -32,7 +32,7 @@ ...@@ -32,7 +32,7 @@
-TODO: at one time or another test that the mode is acceptable by the monitor -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 ...) -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 ... the one ...
-TODO: in set_var check the validity of timings (hsync vsync)... -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 -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); ...@@ -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. * 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 * 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. * I've heard that PIIX also has open drain pin.
* *
......
...@@ -118,7 +118,7 @@ befs_fblock2brun(struct super_block *sb, befs_data_stream * data, ...@@ -118,7 +118,7 @@ befs_fblock2brun(struct super_block *sb, befs_data_stream * data,
* befs_read_lsmylink - read long symlink from datastream. * befs_read_lsmylink - read long symlink from datastream.
* @sb: Filesystem superblock * @sb: Filesystem superblock
* @ds: Datastrem to read from * @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 * @len: Length of the long symlink in bytes
* *
* Returns the number of bytes read * Returns the number of bytes read
......
...@@ -4,7 +4,7 @@ ...@@ -4,7 +4,7 @@
# #
# Stage one of module building created the following: # Stage one of module building created the following:
# a) The individual .o files used for the module # 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 # c) A <module>.mod file in $(MODVERDIR)/, listing the name of the
# the preliminary <module>.o file, plus all .o files # the preliminary <module>.o file, plus all .o files
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册