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/: 'S'
This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letter 'S'. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Alan Cox <alan@redhat.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
d6bc8ac9e1
commit
53cb47268e
@@ -582,7 +582,7 @@ The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
|
||||
and release a global reader-writer lock. The synchronize_rcu()
|
||||
primitive write-acquires this same lock, then immediately releases
|
||||
it. This means that once synchronize_rcu() exits, all RCU read-side
|
||||
critical sections that were in progress before synchonize_rcu() was
|
||||
critical sections that were in progress before synchronize_rcu() was
|
||||
called are guaranteed to have completed -- there is no way that
|
||||
synchronize_rcu() would have been able to write-acquire the lock
|
||||
otherwise.
|
||||
|
||||
@@ -890,7 +890,7 @@ Aside:
|
||||
|
||||
Kvec i/o:
|
||||
|
||||
Ben LaHaise's aio code uses a slighly different structure instead
|
||||
Ben LaHaise's aio code uses a slightly different structure instead
|
||||
of kiobufs, called a kvec_cb. This contains an array of <page, offset, len>
|
||||
tuples (very much like the networking code), together with a callback function
|
||||
and data pointer. This is embedded into a brw_cb structure when passed
|
||||
@@ -988,7 +988,7 @@ elevator_exit_fn Allocate and free any elevator specific storage
|
||||
for a queue.
|
||||
|
||||
4.2 Request flows seen by I/O schedulers
|
||||
All requests seens by I/O schedulers strictly follow one of the following three
|
||||
All requests seen by I/O schedulers strictly follow one of the following three
|
||||
flows.
|
||||
|
||||
set_req_fn ->
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
|
||||
CPU frequency and voltage scaling statictics in the Linux(TM) kernel
|
||||
CPU frequency and voltage scaling statistics in the Linux(TM) kernel
|
||||
|
||||
|
||||
L i n u x c p u f r e q - s t a t s d r i v e r
|
||||
@@ -18,8 +18,8 @@ Contents
|
||||
1. Introduction
|
||||
|
||||
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
|
||||
This statistics is provided in /sysfs as a bunch of read_only interfaces. This
|
||||
interface (when configured) will appear in a seperate directory under cpufreq
|
||||
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
|
||||
interface (when configured) will appear in a separate directory under cpufreq
|
||||
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
||||
Various statistics will form read_only files under this directory.
|
||||
|
||||
@@ -115,7 +115,7 @@ basic statistics which includes time_in_state and total_trans.
|
||||
|
||||
"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS)
|
||||
provides fine grained cpufreq stats by trans_table. The reason for having a
|
||||
seperate config option for trans_table is:
|
||||
separate config option for trans_table is:
|
||||
- trans_table goes against the traditional /sysfs rule of one value per
|
||||
interface. It provides a whole bunch of value in a 2 dimensional matrix
|
||||
form.
|
||||
|
||||
@@ -5,7 +5,7 @@ Hardware supported by the linuxtv.org DVB drivers
|
||||
frontends (i.e. tuner / demodulator units) used, usually without
|
||||
changing the product name, revision number or specs. Some cards
|
||||
are also available in versions with different frontends for
|
||||
DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed seperately.
|
||||
DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed separately.
|
||||
|
||||
Note 1: There is no guarantee that every frontend driver works
|
||||
out of the box with every card, because of different wiring.
|
||||
|
||||
+12
-12
@@ -137,23 +137,23 @@ Bugs
|
||||
- The driver is 16 bpp only, 24/32 won't work.
|
||||
- The driver is not your_favorite_toy-safe. this includes SMP...
|
||||
[Actually from inspection it seems to be safe - Alan]
|
||||
- when using XFree86 FBdev (X over fbdev) you may see strange color
|
||||
- When using XFree86 FBdev (X over fbdev) you may see strange color
|
||||
patterns at the border of your windows (the pixels lose the lowest
|
||||
byte -> basicaly the blue component nd some of the green) . I'm unable
|
||||
byte -> basically the blue component and some of the green). I'm unable
|
||||
to reproduce this with XFree86-3.3, but one of the testers has this
|
||||
problem with XFree86-4. apparently recent Xfree86-4.x solve this
|
||||
problem with XFree86-4. Apparently recent Xfree86-4.x solve this
|
||||
problem.
|
||||
- I didn't really test changing the palette, so you may find some weird
|
||||
things when playing with that.
|
||||
- Sometimes the driver will not recognise the DAC , and the
|
||||
initialisation will fail. this is specificaly true for
|
||||
voodoo 2 boards , but it should be solved in recent versions. please
|
||||
contact me .
|
||||
- the 24/32 is not likely to work anytime soon , knowing that the
|
||||
hardware does ... unusual thigs in 24/32 bpp
|
||||
- When used with anther video board, current limitations of linux
|
||||
console subsystem can cause some troubles, specificaly, you should
|
||||
disable software scrollback , as it can oops badly ...
|
||||
- Sometimes the driver will not recognise the DAC, and the
|
||||
initialisation will fail. This is specifically true for
|
||||
voodoo 2 boards, but it should be solved in recent versions. Please
|
||||
contact me.
|
||||
- The 24/32 is not likely to work anytime soon, knowing that the
|
||||
hardware does ... unusual things in 24/32 bpp.
|
||||
- When used with another video board, current limitations of the linux
|
||||
console subsystem can cause some troubles, specifically, you should
|
||||
disable software scrollback, as it can oops badly ...
|
||||
|
||||
Todo
|
||||
|
||||
|
||||
@@ -254,7 +254,7 @@ using the group _init() functions on the group.
|
||||
|
||||
Finally, when userspace calls rmdir(2) on the item or group,
|
||||
ct_group_ops->drop_item() is called. As a config_group is also a
|
||||
config_item, it is not necessary for a seperate drop_group() method.
|
||||
config_item, it is not necessary for a separate drop_group() method.
|
||||
The subsystem must config_item_put() the reference that was initialized
|
||||
upon item allocation. If a subsystem has no work to do, it may omit
|
||||
the ct_group_ops->drop_item() method, and configfs will call
|
||||
|
||||
@@ -1255,7 +1255,7 @@ to allocate (but not use) more memory than is actually available.
|
||||
address space are refused. Used for a typical system. It
|
||||
ensures a seriously wild allocation fails while allowing
|
||||
overcommit to reduce swap usage. root is allowed to
|
||||
allocate slighly more memory in this mode. This is the
|
||||
allocate slightly more memory in this mode. This is the
|
||||
default.
|
||||
|
||||
1 - Always overcommit. Appropriate for some scientific
|
||||
@@ -1857,7 +1857,7 @@ proxy_qlen
|
||||
|
||||
Maximum queue length of the delayed proxy arp timer. (see proxy_delay).
|
||||
|
||||
app_solcit
|
||||
app_solicit
|
||||
----------
|
||||
|
||||
Determines the number of requests to send to the user level ARP daemon. Use 0
|
||||
|
||||
@@ -58,7 +58,7 @@ several reasons why such integration is hard/impossible:
|
||||
The primary users of precision timers are user-space applications that
|
||||
utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel
|
||||
users like drivers and subsystems which require precise timed events
|
||||
(e.g. multimedia) can benefit from the availability of a seperate
|
||||
(e.g. multimedia) can benefit from the availability of a separate
|
||||
high-resolution timer subsystem as well.
|
||||
|
||||
While this subsystem does not offer high-resolution clock sources just
|
||||
@@ -68,7 +68,7 @@ The increasing demand for realtime and multimedia applications along
|
||||
with other potential users for precise timers gives another reason to
|
||||
separate the "timeout" and "precise timer" subsystems.
|
||||
|
||||
Another potential benefit is that such a seperation allows even more
|
||||
Another potential benefit is that such a separation allows even more
|
||||
special-purpose optimization of the existing timer wheel for the low
|
||||
resolution and low precision use cases - once the precision-sensitive
|
||||
APIs are separated from the timer wheel and are migrated over to
|
||||
@@ -96,8 +96,8 @@ file systems. The rbtree is solely used for time sorted ordering, while
|
||||
a separate list is used to give the expiry code fast access to the
|
||||
queued timers, without having to walk the rbtree.
|
||||
|
||||
(This seperate list is also useful for later when we'll introduce
|
||||
high-resolution clocks, where we need seperate pending and expired
|
||||
(This separate list is also useful for later when we'll introduce
|
||||
high-resolution clocks, where we need separate pending and expired
|
||||
queues while keeping the time-order intact.)
|
||||
|
||||
Time-ordered enqueueing is not purely for the purposes of
|
||||
|
||||
@@ -87,7 +87,7 @@ Line 3 Format : 888888888888
|
||||
|
||||
|
||||
Format description:
|
||||
From a user space perspective the world is seperated in "digits" and "icons".
|
||||
From a userspace perspective the world is separated into "digits" and "icons".
|
||||
A digit can have a character set, an icon can only be ON or OFF.
|
||||
|
||||
Format specifier
|
||||
|
||||
@@ -110,7 +110,7 @@ applicable everywhere (see syntax).
|
||||
the indentation level, this means it ends at the first line which has
|
||||
a smaller indentation than the first line of the help text.
|
||||
"---help---" and "help" do not differ in behaviour, "---help---" is
|
||||
used to help visually seperate configuration logic from help within
|
||||
used to help visually separate configuration logic from help within
|
||||
the file as an aid to developers.
|
||||
|
||||
|
||||
@@ -226,7 +226,7 @@ menuconfig:
|
||||
"menuconfig" <symbol>
|
||||
<config options>
|
||||
|
||||
This is similiar to the simple config entry above, but it also gives a
|
||||
This is similar to the simple config entry above, but it also gives a
|
||||
hint to front ends, that all suboptions should be displayed as a
|
||||
separate list of options.
|
||||
|
||||
|
||||
@@ -262,7 +262,7 @@ which begin with '//' are the comments.
|
||||
// initialised.
|
||||
// AUXP - Auxiliary Pattern Indication - 01010101.. received.
|
||||
// LFA - Loss of Frame Alignment - no frame sync received.
|
||||
// RRA - Receive Remote Alarm - the remote end's OK, but singnals error cond.
|
||||
// RRA - Receive Remote Alarm - the remote end's OK, but signals error cond.
|
||||
// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
|
||||
// NMF - No Multiframe alignment Found after 400 msec - no such alarm using
|
||||
// no-crc4 or crc4 framing, see below.
|
||||
@@ -364,6 +364,6 @@ Treat them very carefully, these can cause much trouble!
|
||||
|
||||
# echo >lbireg 0x1d 0x21
|
||||
|
||||
- Swithing the loop off:
|
||||
- Switching the loop off:
|
||||
|
||||
# echo >lbireg 0x1d 0x00
|
||||
|
||||
@@ -11,7 +11,7 @@ This driver is rather simple to use. Select Y to Token Ring adapter support
|
||||
in the kernel configuration. A choice for SMC Token Ring adapters will
|
||||
appear. This drives supports all SMC ISA/MCA adapters. Choose this
|
||||
option. I personally recommend compiling the driver as a module (M), but if you
|
||||
you would like to compile it staticly answer Y instead.
|
||||
you would like to compile it statically answer Y instead.
|
||||
|
||||
This driver supports multiple adapters without the need to load multiple copies
|
||||
of the driver. You should be able to load up to 7 adapters without any kernel
|
||||
|
||||
@@ -24,7 +24,7 @@ This driver is rather simple to use. Select Y to Token Ring adapter support
|
||||
in the kernel configuration. A choice for SysKonnect Token Ring adapters will
|
||||
appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
|
||||
option. I personally recommend compiling the driver as a module (M), but if you
|
||||
you would like to compile it staticly answer Y instead.
|
||||
you would like to compile it statically answer Y instead.
|
||||
|
||||
This driver supports multiple adapters without the need to load multiple copies
|
||||
of the driver. You should be able to load up to 7 adapters without any kernel
|
||||
|
||||
@@ -9,7 +9,7 @@ If you want to trick swsusp/S3 into working, you might want to try:
|
||||
|
||||
* turn off APIC and preempt
|
||||
|
||||
* use ext2. At least it has working fsck. [If something seemes to go
|
||||
* use ext2. At least it has working fsck. [If something seems to go
|
||||
wrong, force fsck when you have a chance]
|
||||
|
||||
* turn off modules
|
||||
|
||||
@@ -550,11 +550,11 @@ Here's the basic structure of a single node:
|
||||
* [child nodes if any]
|
||||
* token OF_DT_END_NODE (that is 0x00000002)
|
||||
|
||||
So the node content can be summmarised as a start token, a full path,
|
||||
a list of properties, a list of child node and an end token. Every
|
||||
So the node content can be summarised as a start token, a full path,
|
||||
a list of properties, a list of child nodes, and an end token. Every
|
||||
child node is a full node structure itself as defined above.
|
||||
|
||||
4) Device tree 'strings" block
|
||||
4) Device tree "strings" block
|
||||
|
||||
In order to save space, property names, which are generally redundant,
|
||||
are stored separately in the "strings" block. This block is simply the
|
||||
|
||||
@@ -97,7 +97,7 @@ a range of I/O addresses for it to use. The first RocketPort card
|
||||
requires a 68-byte contiguous block of I/O addresses, starting at one
|
||||
of the following: 0x100h, 0x140h, 0x180h, 0x200h, 0x240h, 0x280h,
|
||||
0x300h, 0x340h, 0x380h. This I/O address must be reflected in the DIP
|
||||
switiches of *all* of the Rocketport cards.
|
||||
switches of *all* of the Rocketport cards.
|
||||
|
||||
The second, third, and fourth RocketPort cards require a 64-byte
|
||||
contiguous block of I/O addresses, starting at one of the following
|
||||
|
||||
@@ -317,9 +317,9 @@ Each process/thread under Linux for S390 has its own kernel task_struct
|
||||
defined in linux/include/linux/sched.h
|
||||
The S390 on initialisation & resuming of a process on a cpu sets
|
||||
the __LC_KERNEL_STACK variable in the spare prefix area for this cpu
|
||||
( which we use for per processor globals).
|
||||
(which we use for per-processor globals).
|
||||
|
||||
The kernel stack pointer is intimately tied with the task stucture for
|
||||
The kernel stack pointer is intimately tied with the task structure for
|
||||
each processor as follows.
|
||||
|
||||
s/390
|
||||
@@ -973,8 +973,9 @@ through the pipe for each line containing the string open.
|
||||
|
||||
Example 3
|
||||
---------
|
||||
Getting sophistocated
|
||||
telnetd crashes on & I don't know why
|
||||
Getting sophisticated
|
||||
telnetd crashes & I don't know why
|
||||
|
||||
Steps
|
||||
-----
|
||||
1) Replace the following line in /etc/inetd.conf
|
||||
@@ -1836,7 +1837,7 @@ RDRLIST
|
||||
RECEIVE / LOG TXT A1 ( replace
|
||||
8)
|
||||
filel & press F11 to look at it
|
||||
You should see someting like.
|
||||
You should see something like:
|
||||
|
||||
00020942' SSCH B2334000 0048813C CC 0 SCH 0000 DEV 7C08
|
||||
CPA 000FFDF0 PARM 00E2C9C4 KEY 0 FPI C0 LPM 80
|
||||
|
||||
@@ -83,7 +83,7 @@ This loads the module and sets the DCSS name to "MYDCSS".
|
||||
|
||||
NOTE:
|
||||
-----
|
||||
This API provides no interface to control the *MONITOR service, e.g. specifiy
|
||||
This API provides no interface to control the *MONITOR service, e.g. specify
|
||||
which data should be collected. This can be done by the CP command MONITOR
|
||||
(Class E privileged), see "CP Command and Utility Reference".
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ Introduction
|
||||
-------------------------
|
||||
The aacraid driver adds support for Adaptec (http://www.adaptec.com)
|
||||
RAID controllers. This is a major rewrite from the original
|
||||
Adaptec supplied driver. It has signficantly cleaned up both the code
|
||||
Adaptec supplied driver. It has significantly cleaned up both the code
|
||||
and the running binary size (the module is less than half the size of
|
||||
the original).
|
||||
|
||||
|
||||
@@ -81,7 +81,7 @@ The following information is available in this file:
|
||||
an SDTR with an offset of 0 to be sure the target
|
||||
knows we are async. This works around a firmware defect
|
||||
in the Quantum Atlas 10K.
|
||||
- Implement controller susupend and resume.
|
||||
- Implement controller suspend and resume.
|
||||
- Clear PCI error state during driver attach so that we
|
||||
don't disable memory mapped I/O due to a stray write
|
||||
by some other driver probe that occurred before we
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user