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
Documentation cleanup: trivial misspelling, punctuation, and grammar corrections.
Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
committed by
Linus Torvalds
parent
19fd623127
commit
d91958815d
@@ -48,7 +48,7 @@ IOVA generation is pretty generic. We used the same technique as vmalloc()
|
||||
but these are not global address spaces, but separate for each domain.
|
||||
Different DMA engines may support different number of domains.
|
||||
|
||||
We also allocate gaurd pages with each mapping, so we can attempt to catch
|
||||
We also allocate guard pages with each mapping, so we can attempt to catch
|
||||
any overflow that might happen.
|
||||
|
||||
|
||||
@@ -112,4 +112,4 @@ TBD
|
||||
|
||||
- For compatibility testing, could use unity map domain for all devices, just
|
||||
provide a 1-1 for all useful memory under a single domain for all devices.
|
||||
- API for paravirt ops for abstracting functionlity for VMM folks.
|
||||
- API for paravirt ops for abstracting functionality for VMM folks.
|
||||
|
||||
@@ -6,7 +6,7 @@ This document contains an explanation of the struct taskstats fields.
|
||||
There are three different groups of fields in the struct taskstats:
|
||||
|
||||
1) Common and basic accounting fields
|
||||
If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and
|
||||
If CONFIG_TASKSTATS is set, the taskstats interface is enabled and
|
||||
the common fields and basic accounting fields are collected for
|
||||
delivery at do_exit() of a task.
|
||||
2) Delay accounting fields
|
||||
|
||||
@@ -122,7 +122,7 @@ around '10000' or more.
|
||||
show_sampling_rate_(min|max): the minimum and maximum sampling rates
|
||||
available that you may set 'sampling_rate' to.
|
||||
|
||||
up_threshold: defines what the average CPU usaged between the samplings
|
||||
up_threshold: defines what the average CPU usage between the samplings
|
||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||
whether it should increase the frequency. For example when it is set
|
||||
to its default value of '80' it means that between the checking
|
||||
|
||||
@@ -327,7 +327,7 @@ Sdram memory scrubbing rate:
|
||||
'sdram_scrub_rate'
|
||||
|
||||
Read/Write attribute file that controls memory scrubbing. The scrubbing
|
||||
rate is set by writing a minimum bandwith in bytes/sec to the attribute
|
||||
rate is set by writing a minimum bandwidth in bytes/sec to the attribute
|
||||
file. The rate will be translated to an internal value that gives at
|
||||
least the specified rate.
|
||||
|
||||
|
||||
@@ -931,7 +931,7 @@ group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
|
||||
stats stream_req
|
||||
|
||||
mb_groups:
|
||||
This file gives the details of mutiblock allocator buddy cache of free blocks
|
||||
This file gives the details of multiblock allocator buddy cache of free blocks
|
||||
|
||||
mb_history:
|
||||
Multiblock allocation history.
|
||||
@@ -1474,7 +1474,7 @@ used because pages_free(1355) is smaller than watermark + protection[2]
|
||||
normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
||||
(=0) is used.
|
||||
|
||||
zone[i]'s protection[j] is calculated by following exprssion.
|
||||
zone[i]'s protection[j] is calculated by following expression.
|
||||
|
||||
(i < j):
|
||||
zone[i]->protection[j]
|
||||
|
||||
@@ -143,7 +143,7 @@ struct file_system_type {
|
||||
|
||||
The get_sb() method has the following arguments:
|
||||
|
||||
struct file_system_type *fs_type: decribes the filesystem, partly initialized
|
||||
struct file_system_type *fs_type: describes the filesystem, partly initialized
|
||||
by the specific filesystem code
|
||||
|
||||
int flags: mount flags
|
||||
@@ -895,9 +895,9 @@ struct dentry_operations {
|
||||
iput() yourself
|
||||
|
||||
d_dname: called when the pathname of a dentry should be generated.
|
||||
Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||
Useful for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||
pathname generation. (Instead of doing it when dentry is created,
|
||||
its done only when the path is needed.). Real filesystems probably
|
||||
it's done only when the path is needed.). Real filesystems probably
|
||||
dont want to use it, because their dentries are present in global
|
||||
dcache hash, so their hash should be an invariant. As no lock is
|
||||
held, d_dname() should not try to modify the dentry itself, unless
|
||||
|
||||
@@ -50,9 +50,9 @@ Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qe
|
||||
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
|
||||
(xx is the number of virtual processors for the guest, now the maximum value is 4)
|
||||
|
||||
5. Known possibile issue on some platforms with old Firmware.
|
||||
5. Known possible issue on some platforms with old Firmware.
|
||||
|
||||
If meet strange host crashe issues, try to solve it through either of the following ways:
|
||||
In the event of strange host crash issues, try to solve it through either of the following ways:
|
||||
|
||||
(1): Upgrade your Firmware to the latest one.
|
||||
|
||||
@@ -65,8 +65,8 @@ index 0b53344..f02b0f7 100644
|
||||
mov ar.pfs = loc1
|
||||
mov rp = loc0
|
||||
;;
|
||||
- srlz.d // seralize restoration of psr.l
|
||||
+ srlz.i // seralize restoration of psr.l
|
||||
- srlz.d // serialize restoration of psr.l
|
||||
+ srlz.i // serialize restoration of psr.l
|
||||
+ ;;
|
||||
br.ret.sptk.many b0
|
||||
END(ia64_pal_call_static)
|
||||
|
||||
@@ -31,7 +31,7 @@ The driver works with ALSA drivers simultaneously. For example, the xracer
|
||||
uses joystick as input device and PCM device as sound output in one time.
|
||||
There are no sound or input collisions detected. The source code have
|
||||
comments about them; but I've found the joystick can be initialized
|
||||
separately of ALSA modules. So, you canm use only one joystick driver
|
||||
separately of ALSA modules. So, you can use only one joystick driver
|
||||
without ALSA drivers. The ALSA drivers are not needed to compile or
|
||||
run this driver.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
To decode a hex IOCTL code:
|
||||
|
||||
Most architecures use this generic format, but check
|
||||
Most architectures use this generic format, but check
|
||||
include/ARCH/ioctl.h for specifics, e.g. powerpc
|
||||
uses 3 bits to encode read/write and 13 bits for size.
|
||||
|
||||
@@ -18,7 +18,7 @@ uses 3 bits to encode read/write and 13 bits for size.
|
||||
7-0 function #
|
||||
|
||||
|
||||
So for example 0x82187201 is a read with arg length of 0x218,
|
||||
So for example 0x82187201 is a read with arg length of 0x218,
|
||||
character 'r' function 1. Grepping the source reveals this is:
|
||||
|
||||
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
|
||||
|
||||
@@ -143,7 +143,7 @@ disk and partition statistics are consistent again. Since we still don't
|
||||
keep record of the partition-relative address, an operation is attributed to
|
||||
the partition which contains the first sector of the request after the
|
||||
eventual merges. As requests can be merged across partition, this could lead
|
||||
to some (probably insignificant) innacuracy.
|
||||
to some (probably insignificant) inaccuracy.
|
||||
|
||||
Additional notes
|
||||
----------------
|
||||
|
||||
@@ -864,7 +864,7 @@ payload contents" for more information.
|
||||
request_key_with_auxdata() respectively.
|
||||
|
||||
These two functions return with the key potentially still under
|
||||
construction. To wait for contruction completion, the following should be
|
||||
construction. To wait for construction completion, the following should be
|
||||
called:
|
||||
|
||||
int wait_for_key_construction(struct key *key, bool intr);
|
||||
|
||||
@@ -59,7 +59,7 @@ Hardware accelerated blink of LEDs
|
||||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemeted, triggers can
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
|
||||
@@ -36,7 +36,7 @@ It can be done by slightly modifying the standard atomic operations : only
|
||||
their UP variant must be kept. It typically means removing LOCK prefix (on
|
||||
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
|
||||
not have a different behavior between SMP and UP, including asm-generic/local.h
|
||||
in your archtecture's local.h is sufficient.
|
||||
in your architecture's local.h is sufficient.
|
||||
|
||||
The local_t type is defined as an opaque signed long by embedding an
|
||||
atomic_long_t inside a structure. This is made so a cast from this type to a
|
||||
|
||||
@@ -631,7 +631,7 @@ xmit_hash_policy
|
||||
in environments where a layer3 gateway device is
|
||||
required to reach most destinations.
|
||||
|
||||
This algorithm is 802.3ad complient.
|
||||
This algorithm is 802.3ad compliant.
|
||||
|
||||
layer3+4
|
||||
|
||||
|
||||
@@ -186,7 +186,7 @@ solution for a couple of reasons:
|
||||
|
||||
The Linux network devices (by default) just can handle the
|
||||
transmission and reception of media dependent frames. Due to the
|
||||
arbritration on the CAN bus the transmission of a low prio CAN-ID
|
||||
arbitration on the CAN bus the transmission of a low prio CAN-ID
|
||||
may be delayed by the reception of a high prio CAN frame. To
|
||||
reflect the correct* traffic on the node the loopback of the sent
|
||||
data has to be performed right after a successful transmission. If
|
||||
@@ -481,7 +481,7 @@ solution for a couple of reasons:
|
||||
- stats_timer: To calculate the Socket CAN core statistics
|
||||
(e.g. current/maximum frames per second) this 1 second timer is
|
||||
invoked at can.ko module start time by default. This timer can be
|
||||
disabled by using stattimer=0 on the module comandline.
|
||||
disabled by using stattimer=0 on the module commandline.
|
||||
|
||||
- debug: (removed since SocketCAN SVN r546)
|
||||
|
||||
|
||||
@@ -326,7 +326,7 @@ just one call to mmap is needed:
|
||||
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
|
||||
If tp_frame_size is a divisor of tp_block_size frames will be
|
||||
contiguosly spaced by tp_frame_size bytes. If not, each
|
||||
contiguously spaced by tp_frame_size bytes. If not, each
|
||||
tp_block_size/tp_frame_size frames there will be a gap between
|
||||
the frames. This is because a frame cannot be spawn across two
|
||||
blocks.
|
||||
|
||||
@@ -4,26 +4,27 @@ The "enviromental" rules for authors of any new tc actions are:
|
||||
1) If you stealeth or borroweth any packet thou shalt be branching
|
||||
from the righteous path and thou shalt cloneth.
|
||||
|
||||
For example if your action queues a packet to be processed later
|
||||
or intentionaly branches by redirecting a packet then you need to
|
||||
For example if your action queues a packet to be processed later,
|
||||
or intentionally branches by redirecting a packet, then you need to
|
||||
clone the packet.
|
||||
|
||||
There are certain fields in the skb tc_verd that need to be reset so we
|
||||
avoid loops etc. A few are generic enough so much so that skb_act_clone()
|
||||
resets them for you. So invoke skb_act_clone() rather than skb_clone()
|
||||
avoid loops, etc. A few are generic enough that skb_act_clone()
|
||||
resets them for you, so invoke skb_act_clone() rather than skb_clone().
|
||||
|
||||
2) If you munge any packet thou shalt call pskb_expand_head in the case
|
||||
someone else is referencing the skb. After that you "own" the skb.
|
||||
You must also tell us if it is ok to munge the packet (TC_OK2MUNGE),
|
||||
this way any action downstream can stomp on the packet.
|
||||
|
||||
3) dropping packets you dont own is a nono. You simply return
|
||||
3) Dropping packets you don't own is a no-no. You simply return
|
||||
TC_ACT_SHOT to the caller and they will drop it.
|
||||
|
||||
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
||||
|
||||
*) thou art responsible for freeing anything returned as being
|
||||
*) Thou art responsible for freeing anything returned as being
|
||||
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
||||
returned then all is great and you dont need to do anything.
|
||||
returned, then all is great and you don't need to do anything.
|
||||
|
||||
Post on netdev if something is unclear.
|
||||
|
||||
|
||||
@@ -708,7 +708,7 @@ device or bus to be described by the device tree.
|
||||
In general, the format of an address for a device is defined by the
|
||||
parent bus type, based on the #address-cells and #size-cells
|
||||
properties. Note that the parent's parent definitions of #address-cells
|
||||
and #size-cells are not inhereted so every node with children must specify
|
||||
and #size-cells are not inherited so every node with children must specify
|
||||
them. The kernel requires the root node to have those properties defining
|
||||
addresses format for devices directly mapped on the processor bus.
|
||||
|
||||
@@ -1777,7 +1777,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
|
||||
Xilinx uartlite devices are simple fixed speed serial ports.
|
||||
|
||||
Requred properties:
|
||||
Required properties:
|
||||
- current-speed : Baud rate of uartlite
|
||||
|
||||
v) Xilinx hwicap
|
||||
@@ -1799,7 +1799,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
Xilinx UART 16550 devices are very similar to the NS16550 but with
|
||||
different register spacing and an offset from the base address.
|
||||
|
||||
Requred properties:
|
||||
Required properties:
|
||||
- clock-frequency : Frequency of the clock input
|
||||
- reg-offset : A value of 3 is required
|
||||
- reg-shift : A value of 2 is required
|
||||
@@ -1953,7 +1953,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
|
||||
1) The /system-controller node
|
||||
|
||||
This node is used to represent the system-controller and must be
|
||||
present when the system uses a system contller chip. The top-level
|
||||
present when the system uses a system controller chip. The top-level
|
||||
system-controller node contains information that is global to all
|
||||
devices within the system controller chip. The node name begins
|
||||
with "system-controller" followed by the unit address, which is
|
||||
|
||||
@@ -217,7 +217,7 @@ Although it is not recommended, you can specify '0' in the soc.model
|
||||
field to skip matching SOCs altogether.
|
||||
|
||||
The 'model' field is a 16-bit number that matches the actual SOC. The
|
||||
'major' and 'minor' fields are the major and minor revision numbrs,
|
||||
'major' and 'minor' fields are the major and minor revision numbers,
|
||||
respectively, of the SOC.
|
||||
|
||||
For example, to match the 8323, revision 1.0:
|
||||
|
||||
@@ -25,7 +25,7 @@ device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
|
||||
subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
|
||||
|
||||
The subchannel named 'defunct' does not represent any real subchannel on the
|
||||
system; it is a pseudo subchannel where disconnnected ccw devices are moved to
|
||||
system; it is a pseudo subchannel where disconnected ccw devices are moved to
|
||||
if they are displaced by another ccw device becoming operational on their
|
||||
former subchannel. The ccw devices will be moved again to a proper subchannel
|
||||
if they become operational again on that subchannel.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user