You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Fix typos in Documentation/: 'N'-'P'
This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letters 'N'-'P'. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
committed by
Adrian Bunk
parent
2fe0ae78c6
commit
992caacf11
@@ -38,7 +38,7 @@ MTD
|
||||
---
|
||||
|
||||
The NAND and NOR support has been merged from the linux-mtd project.
|
||||
Any prolbems, see http://www.linux-mtd.infradead.org/ for more
|
||||
Any problems, see http://www.linux-mtd.infradead.org/ for more
|
||||
information or up-to-date versions of linux-mtd.
|
||||
|
||||
|
||||
|
||||
@@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller
|
||||
at a time during a write batch. It is this characteristic that can make
|
||||
the anticipatory scheduler perform anomalously with controllers supporting
|
||||
TCQ, or with hardware striped RAID devices. Setting the antic_expire
|
||||
queue paramter (see below) to zero disables this behavior, and the anticipatory
|
||||
scheduler behaves essentially like the deadline scheduler.
|
||||
queue parameter (see below) to zero disables this behavior, and the
|
||||
anticipatory scheduler behaves essentially like the deadline scheduler.
|
||||
|
||||
When read anticipation is enabled (antic_expire is not zero), reads
|
||||
are dispatched to the disk controller one at a time.
|
||||
|
||||
@@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case
|
||||
of ii. Just keeping issue order suffices. Ancient SCSI
|
||||
controllers/drives and IDE drives are in this category.
|
||||
|
||||
2. Forced flushing to physcial medium
|
||||
2. Forced flushing to physical medium
|
||||
|
||||
Again, if you're not gonna do synchronization with disk drives (dang,
|
||||
it sounds even more appealing now!), the reason you use I/O barriers
|
||||
|
||||
@@ -137,11 +137,11 @@ have to be made in a row before the CPU frequency is actually lower.
|
||||
If set to '1' then the frequency decreases as quickly as it increases,
|
||||
if set to '2' it decreases at half the rate of the increase.
|
||||
|
||||
ignore_nice_load: this parameter takes a value of '0' or '1', when set
|
||||
to '0' (its default) then all processes are counted towards towards the
|
||||
'cpu utilisation' value. When set to '1' then processes that are
|
||||
ignore_nice_load: this parameter takes a value of '0' or '1'. When
|
||||
set to '0' (its default), all processes are counted towards the
|
||||
'cpu utilisation' value. When set to '1', the processes that are
|
||||
run with a 'nice' value will not count (and thus be ignored) in the
|
||||
overal usage calculation. This is useful if you are running a CPU
|
||||
overall usage calculation. This is useful if you are running a CPU
|
||||
intensive calculation on your laptop that you do not care how long it
|
||||
takes to complete as you can 'nice' it and prevent it from taking part
|
||||
in the deciding process of whether to increase your CPU frequency.
|
||||
|
||||
@@ -52,7 +52,7 @@ echo packet > /sys/devices/platform/dell_rbu/image_type
|
||||
In packet update mode the packet size has to be given before any packets can
|
||||
be downloaded. It is done as below
|
||||
echo XXXX > /sys/devices/platform/dell_rbu/packet_size
|
||||
In the packet update mechanism, the user neesd to create a new file having
|
||||
In the packet update mechanism, the user needs to create a new file having
|
||||
packets of data arranged back to back. It can be done as follows
|
||||
The user creates packets header, gets the chunk of the BIOS image and
|
||||
places it next to the packetheader; now, the packetheader + BIOS image chunk
|
||||
@@ -93,8 +93,8 @@ read back the image downloaded.
|
||||
NOTE:
|
||||
This driver requires a patch for firmware_class.c which has the modified
|
||||
request_firmware_nowait function.
|
||||
Also after updating the BIOS image an user mdoe application neeeds to execute
|
||||
code which message the BIOS update request to the BIOS. So on the next reboot
|
||||
the BIOS knows about the new image downloaded and it updates it self.
|
||||
Also don't unload the rbu drive if the image has to be updated.
|
||||
Also after updating the BIOS image a user mode application needs to execute
|
||||
code which sends the BIOS update request to the BIOS. So on the next reboot
|
||||
the BIOS knows about the new image downloaded and it updates itself.
|
||||
Also don't unload the rbu driver if the image has to be updated.
|
||||
|
||||
|
||||
@@ -2005,7 +2005,7 @@ Your cooperation is appreciated.
|
||||
116 char Advanced Linux Sound Driver (ALSA)
|
||||
|
||||
116 block MicroMemory battery backed RAM adapter (NVRAM)
|
||||
Supports 16 boards, 15 paritions each.
|
||||
Supports 16 boards, 15 partitions each.
|
||||
Requested by neilb at cse.unsw.edu.au.
|
||||
|
||||
0 = /dev/umem/d0 Whole of first board
|
||||
@@ -3094,7 +3094,7 @@ Your cooperation is appreciated.
|
||||
This major is reserved to assist the expansion to a
|
||||
larger number space. No device nodes with this major
|
||||
should ever be created on the filesystem.
|
||||
(This is probaly not true anymore, but I'll leave it
|
||||
(This is probably not true anymore, but I'll leave it
|
||||
for now /Torben)
|
||||
|
||||
---LARGE MAJORS!!!!!---
|
||||
|
||||
@@ -45,9 +45,9 @@ Assumptions and Introduction
|
||||
by circuitry on the card and is often presented uncompressed.
|
||||
For a PAL TV signal encoded at a resolution of 768x576 24-bit
|
||||
color pixels over 25 frames per second - a fair amount of data
|
||||
is generated and must be proceesed by the PC before it can be
|
||||
is generated and must be processed by the PC before it can be
|
||||
displayed on the video monitor screen. Some Analogue TV cards
|
||||
for PC's have onboard MPEG2 encoders which permit the raw
|
||||
for PCs have onboard MPEG2 encoders which permit the raw
|
||||
digital data stream to be presented to the PC in an encoded
|
||||
and compressed form - similar to the form that is used in
|
||||
Digital TV.
|
||||
|
||||
@@ -5,7 +5,7 @@ Some very frequently asked questions about linuxtv-dvb
|
||||
It's not a bug, it's a feature. Because the frontends have
|
||||
significant power requirements (and hence get very hot), they
|
||||
are powered down if they are unused (i.e. if the frontend device
|
||||
is closed). The dvb-core.o module paramter "dvb_shutdown_timeout"
|
||||
is closed). The dvb-core.o module parameter "dvb_shutdown_timeout"
|
||||
allow you to change the timeout (default 5 seconds). Setting the
|
||||
timeout to 0 disables the timeout feature.
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ struct eisa_driver {
|
||||
|
||||
id_table : an array of NULL terminated EISA id strings,
|
||||
followed by an empty string. Each string can
|
||||
optionnaly be paired with a driver-dependant value
|
||||
optionally be paired with a driver-dependant value
|
||||
(driver_data).
|
||||
|
||||
driver : a generic driver, such as described in
|
||||
|
||||
@@ -72,8 +72,8 @@ Module Usage
|
||||
|
||||
Kernel/Modules Options
|
||||
|
||||
You can pass some otions to sstfb module, and via the kernel command
|
||||
line when the driver is compiled in :
|
||||
You can pass some options to the sstfb module, and via the kernel
|
||||
command line when the driver is compiled in:
|
||||
for module : insmod sstfb.o option1=value1 option2=value2 ...
|
||||
in kernel : video=sstfb:option1,option2:value2,option3 ...
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ He has been working on the code since Aug 13, 2001. See the changelog for
|
||||
details.
|
||||
|
||||
Original Author: Makoto Kato <m_kato@ga2.so-net.ne.jp>
|
||||
His orriginal code can still be found at:
|
||||
His original code can still be found at:
|
||||
<http://hp.vector.co.jp/authors/VA008030/bfs/>
|
||||
Does anyone know of a more current email address for Makoto? He doesn't
|
||||
respond to the address given above...
|
||||
@@ -39,7 +39,7 @@ Which is it, BFS or BEFS?
|
||||
================
|
||||
Be, Inc said, "BeOS Filesystem is officially called BFS, not BeFS".
|
||||
But Unixware Boot Filesystem is called bfs, too. And they are already in
|
||||
the kernel. Because of this nameing conflict, on Linux the BeOS
|
||||
the kernel. Because of this naming conflict, on Linux the BeOS
|
||||
filesystem is called befs.
|
||||
|
||||
HOW TO INSTALL
|
||||
|
||||
@@ -205,7 +205,7 @@ Reserved Space
|
||||
|
||||
In ext2, there is a mechanism for reserving a certain number of blocks
|
||||
for a particular user (normally the super-user). This is intended to
|
||||
allow for the system to continue functioning even if non-priveleged users
|
||||
allow for the system to continue functioning even if non-privileged users
|
||||
fill up all the space available to them (this is independent of filesystem
|
||||
quotas). It also keeps the filesystem from filling up entirely which
|
||||
helps combat fragmentation.
|
||||
|
||||
@@ -359,7 +359,7 @@ ERRORS
|
||||
EFAULT npc is not a valid pointer or status is neither NULL nor a valid
|
||||
pointer.
|
||||
|
||||
EINTR A signal occured while spu_run was in progress. The npc value
|
||||
EINTR A signal occurred while spu_run was in progress. The npc value
|
||||
has been updated to the new program counter value if necessary.
|
||||
|
||||
EINVAL fd is not a file descriptor returned from spu_create(2).
|
||||
|
||||
@@ -27,7 +27,7 @@ several reasons why such integration is hard/impossible:
|
||||
high-res timers.
|
||||
|
||||
- the unpredictable [O(N)] overhead of cascading leads to delays which
|
||||
necessiate a more complex handling of high resolution timers, which
|
||||
necessitate a more complex handling of high resolution timers, which
|
||||
in turn decreases robustness. Such a design still led to rather large
|
||||
timing inaccuracies. Cascading is a fundamental property of the timer
|
||||
wheel concept, it cannot be 'designed out' without unevitably
|
||||
|
||||
@@ -465,8 +465,8 @@ more parallel ports.
|
||||
|
||||
There are two options specific to PSX driver portion. gamecon.psx_delay sets
|
||||
the command delay when talking to the controllers. The default of 25 should
|
||||
work but you can try lowering it for better performace. If your pads don't
|
||||
respond try raising it untill they work. Setting the type to 8 allows the
|
||||
work but you can try lowering it for better performance. If your pads don't
|
||||
respond try raising it until they work. Setting the type to 8 allows the
|
||||
driver to be used with Dance Dance Revolution or similar games. Arrow keys are
|
||||
registered as key presses instead of X and Y axes.
|
||||
|
||||
|
||||
@@ -170,7 +170,7 @@ Proof of 100% correctness:
|
||||
|
||||
The validator achieves perfect, mathematical 'closure' (proof of locking
|
||||
correctness) in the sense that for every simple, standalone single-task
|
||||
locking sequence that occured at least once during the lifetime of the
|
||||
locking sequence that occurred at least once during the lifetime of the
|
||||
kernel, the validator proves it with a 100% certainty that no
|
||||
combination and timing of these locking sequences can cause any class of
|
||||
lock related deadlock. [*]
|
||||
|
||||
@@ -330,7 +330,7 @@ Each directory contains:
|
||||
This gives the role that the device has in the array. It will
|
||||
either be 'none' if the device is not active in the array
|
||||
(i.e. is a spare or has failed) or an integer less than the
|
||||
'raid_disks' number for the array indicating which possition
|
||||
'raid_disks' number for the array indicating which position
|
||||
it currently fills. This can only be set while assembling an
|
||||
array. A device for which this is set is assumed to be working.
|
||||
|
||||
@@ -353,7 +353,7 @@ in the array. These are named
|
||||
|
||||
rdNN
|
||||
|
||||
where 'NN' is the possition in the array, starting from 0.
|
||||
where 'NN' is the position in the array, starting from 0.
|
||||
So for a 3 drive array there will be rd0, rd1, rd2.
|
||||
These are symbolic links to the appropriate 'dev-XXX' entry.
|
||||
Thus, for example,
|
||||
|
||||
@@ -79,8 +79,8 @@ Rate Estimator:
|
||||
|
||||
0) Prepare an estimator attribute. Most likely this would be in user
|
||||
space. The value of this TLV should contain a tc_estimator structure.
|
||||
As usual, such a TLV nees to be 32 bit aligned and therefore the
|
||||
length needs to be appropriately set etc. The estimator interval
|
||||
As usual, such a TLV needs to be 32 bit aligned and therefore the
|
||||
length needs to be appropriately set, etc. The estimator interval
|
||||
and ewma log need to be converted to the appropriate values.
|
||||
tc_estimator.c::tc_setup_estimator() is advisable to be used as the
|
||||
conversion routine. It does a few clever things. It takes a time
|
||||
|
||||
@@ -278,7 +278,7 @@ an i386 kernel's memory size is limited to 1GiB.
|
||||
All memory allocations are not freed until the socket is closed. The memory
|
||||
allocations are done with GFP_KERNEL priority, this basically means that
|
||||
the allocation can wait and swap other process' memory in order to allocate
|
||||
the nececessary memory, so normally limits can be reached.
|
||||
the necessary memory, so normally limits can be reached.
|
||||
|
||||
Other constraints
|
||||
-------------------
|
||||
|
||||
@@ -180,7 +180,7 @@ To set the driver parameters in this file, proceed as follows:
|
||||
1. Insert a line of the form :
|
||||
options sk98lin ...
|
||||
For "...", the same syntax is required as described for the command
|
||||
line paramaters of modprobe below.
|
||||
line parameters of modprobe below.
|
||||
2. To activate the new parameters, either reboot your computer
|
||||
or
|
||||
unload and reload the driver.
|
||||
@@ -364,9 +364,9 @@ Parameter: IntsPerSec
|
||||
Values: 30...40000 (interrupts per second)
|
||||
Default: 2000
|
||||
|
||||
This parameter is only used, if either static or dynamic interrupt moderation
|
||||
is used on a network adapter card. Using this paramter if no moderation is
|
||||
applied, will lead to no action performed.
|
||||
This parameter is only used if either static or dynamic interrupt moderation
|
||||
is used on a network adapter card. Using this parameter if no moderation is
|
||||
applied will lead to no action performed.
|
||||
|
||||
This parameter determines the length of any interrupt moderation interval.
|
||||
Assuming that static interrupt moderation is to be used, an 'IntsPerSec'
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user