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
Merge tag 'docs-for-linus' of git://git.lwn.net/linux
Pull Documentation updates from Jon Corbet: "A bit busier this time around. The most interesting thing (IMO) this time around is some beginning infrastructural work to allow documents to be written using restructured text. Maybe someday, in a galaxy far far away, we'll be able to eliminate the DocBook dependency and have a much better integrated set of kernel docs. Someday. Beyond that, there's a new document on security hardening from Kees, the movement of some sample code over to samples/, a number of improvements to the serial docs from Geert, and the usual collection of corrections, typo fixes, etc" * tag 'docs-for-linus' of git://git.lwn.net/linux: (55 commits) doc: self-protection: provide initial details serial: doc: Use port->state instead of info serial: doc: Always refer to tty_port->mutex Documentation: vm: Spelling s/paltform/platform/g Documentation/memcg: update kmem limit doc as codes behavior docproc: print a comment about autogeneration for rst output docproc: add support for reStructuredText format via --rst option docproc: abstract terminating lines at first space docproc: abstract docproc directive detection docproc: reduce unnecessary indentation docproc: add variables for subcommand and filename kernel-doc: use rst C domain directives and references for types kernel-doc: produce RestructuredText output kernel-doc: rewrite usage description, remove duplicated comments Doc: correct the location of sysrq.c Documentation: fix common spelling mistakes samples: v4l: from Documentation to samples directory samples: connector: from Documentation to samples directory Documentation: xillybus: fix spelling mistake Documentation: x86: fix spelling mistakes ...
This commit is contained in:
@@ -3,9 +3,10 @@ Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. buttons holds informations about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons to the mouse. The data has to be 47 bytes long.
|
||||
button settings. The buttons variable holds information about
|
||||
button layout. When written, this file lets one write the
|
||||
respective profile buttons to the mouse. The data has to be
|
||||
47 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
@@ -26,8 +27,8 @@ Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. profile holds informations like resolution, sensitivity
|
||||
and light effects.
|
||||
button settings. A profile holds information like resolution,
|
||||
sensitivity and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
|
||||
@@ -4,7 +4,7 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
Description:
|
||||
Provides access to the binary "24x7 catalog" provided by the
|
||||
hypervisor on POWER7 and 8 systems. This catalog lists events
|
||||
avaliable from the powerpc "hv_24x7" pmu. Its format is
|
||||
available from the powerpc "hv_24x7" pmu. Its format is
|
||||
documented here:
|
||||
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
|
||||
|
||||
|
||||
@@ -39,5 +39,5 @@ Description: Make it possible to adjust defio refresh rate.
|
||||
Note: As device can barely do 2 complete refreshes a second
|
||||
it only makes sense to adjust this value if only one or two
|
||||
tiles get changed and it's not appropriate to expect the application
|
||||
to flush it's tiny changes explicitely at higher than default rate.
|
||||
to flush its tiny changes explicitly at higher than default rate.
|
||||
|
||||
|
||||
@@ -169,7 +169,7 @@ Description:
|
||||
to enable/disable/clear ACPI interrupts in user space, which can be
|
||||
used to debug some ACPI interrupt storm issues.
|
||||
|
||||
Note that only writting to VALID GPE/Fixed Event is allowed,
|
||||
Note that only writing to VALID GPE/Fixed Event is allowed,
|
||||
i.e. user can only change the status of runtime GPE and
|
||||
Fixed Event with event handler installed.
|
||||
|
||||
|
||||
@@ -2841,7 +2841,7 @@ for a GOP and keep it below or equal the set bitrate target. Otherwise the rate
|
||||
overall average bitrate for the stream and keeps it below or equal to the set bitrate. In the first case
|
||||
the average bitrate for the whole stream will be smaller then the set bitrate. This is caused because the
|
||||
average is calculated for smaller number of frames, on the other hand enabling this setting will ensure that
|
||||
the stream will meet tight bandwidth contraints. Applicable to encoders.
|
||||
the stream will meet tight bandwidth constraints. Applicable to encoders.
|
||||
</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
|
||||
@@ -85,7 +85,7 @@ initialize all fields of the &v4l2-vbi-format;
|
||||
results of <constant>VIDIOC_G_FMT</constant>, and call the
|
||||
&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers return
|
||||
an &EINVAL; only when the given parameters are ambiguous, otherwise
|
||||
they modify the parameters according to the hardware capabilites and
|
||||
they modify the parameters according to the hardware capabilities and
|
||||
return the actual parameters. When the driver allocates resources at
|
||||
this point, it may return an &EBUSY; to indicate the returned
|
||||
parameters are valid but the required resources are currently not
|
||||
|
||||
@@ -216,7 +216,7 @@ or the <structfield>flags</structfield> argument is not valid.</para>
|
||||
<term><errorcode>ERANGE</errorcode></term>
|
||||
<listitem>
|
||||
<para>It is not possible to adjust &v4l2-rect; <structfield>
|
||||
r</structfield> rectangle to satisfy all contraints given in the
|
||||
r</structfield> rectangle to satisfy all constraints given in the
|
||||
<structfield>flags</structfield> argument.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@@ -70,6 +70,7 @@ of the reverse map types are described below:
|
||||
|
||||
==== Linear ====
|
||||
irq_domain_add_linear()
|
||||
irq_domain_create_linear()
|
||||
|
||||
The linear reverse map maintains a fixed size table indexed by the
|
||||
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
|
||||
@@ -81,10 +82,16 @@ map are fixed time lookup for IRQ numbers, and irq_descs are only
|
||||
allocated for in-use IRQs. The disadvantage is that the table must be
|
||||
as large as the largest possible hwirq number.
|
||||
|
||||
irq_domain_add_linear() and irq_domain_create_linear() are functionally
|
||||
equivalent, except for the first argument is different - the former
|
||||
accepts an Open Firmware specific 'struct device_node', while the latter
|
||||
accepts a more general abstraction 'struct fwnode_handle'.
|
||||
|
||||
The majority of drivers should use the linear map.
|
||||
|
||||
==== Tree ====
|
||||
irq_domain_add_tree()
|
||||
irq_domain_create_tree()
|
||||
|
||||
The irq_domain maintains a radix tree map from hwirq numbers to Linux
|
||||
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
|
||||
@@ -95,6 +102,11 @@ since it doesn't need to allocate a table as large as the largest
|
||||
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
|
||||
dependent on how many entries are in the table.
|
||||
|
||||
irq_domain_add_tree() and irq_domain_create_tree() are functionally
|
||||
equivalent, except for the first argument is different - the former
|
||||
accepts an Open Firmware specific 'struct device_node', while the latter
|
||||
accepts a more general abstraction 'struct fwnode_handle'.
|
||||
|
||||
Very few drivers should need this mapping.
|
||||
|
||||
==== No Map ===-
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
subdir-y := accounting auxdisplay blackfin connector \
|
||||
subdir-y := accounting auxdisplay blackfin \
|
||||
filesystems filesystems ia64 laptops mic misc-devices \
|
||||
networking pcmcia prctl ptp timers vDSO watchdog
|
||||
|
||||
@@ -176,13 +176,13 @@ a history of how Linux changed RCU more than RCU changed Linux
|
||||
which Mathieu Desnoyers is now maintaining [MathieuDesnoyers2009URCU]
|
||||
[MathieuDesnoyersPhD]. TINY_RCU [PaulEMcKenney2009BloatWatchRCU] made
|
||||
its appearance, as did expedited RCU [PaulEMcKenney2009expeditedRCU].
|
||||
The problem of resizeable RCU-protected hash tables may now be on a path
|
||||
The problem of resizable RCU-protected hash tables may now be on a path
|
||||
to a solution [JoshTriplett2009RPHash]. A few academic researchers are now
|
||||
using RCU to solve their parallel problems [HariKannan2009DynamicAnalysisRCU].
|
||||
|
||||
2010 produced a simpler preemptible-RCU implementation
|
||||
based on TREE_RCU [PaulEMcKenney2010SimpleOptRCU], lockdep-RCU
|
||||
[PaulEMcKenney2010LockdepRCU], another resizeable RCU-protected hash
|
||||
[PaulEMcKenney2010LockdepRCU], another resizable RCU-protected hash
|
||||
table [HerbertXu2010RCUResizeHash] (this one consuming more memory,
|
||||
but allowing arbitrary changes in hash function, as required for DoS
|
||||
avoidance in the networking code), realization of the 2009 RCU-protected
|
||||
@@ -193,7 +193,7 @@ the RCU API [PaulEMcKenney2010RCUAPI].
|
||||
[LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS], an RCU-protected red-black
|
||||
tree using software transactional memory to protect concurrent updates
|
||||
(strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of
|
||||
RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU
|
||||
RCU-protected resizable hash tables [Triplett:2011:RPHash], the 3.0 RCU
|
||||
trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the
|
||||
Lockers" LWN article [NeilBrown2011MeetTheLockers]. Some academic
|
||||
work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425].
|
||||
|
||||
@@ -136,7 +136,7 @@ an fxyzzy(3) operation for free:
|
||||
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
|
||||
|
||||
(For more details on the rationale of the *at() calls, see the openat(2) man
|
||||
page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
|
||||
page; for an example of AT_EMPTY_PATH, see the fstatat(2) man page.)
|
||||
|
||||
If your new xyzzy(2) system call involves a parameter describing an offset
|
||||
within a file, make its type loff_t so that 64-bit offsets can be supported
|
||||
|
||||
@@ -214,7 +214,7 @@ RedBoot scripting
|
||||
-----------------
|
||||
|
||||
All the commands above aren't so useful if they have to be typed in every
|
||||
time the Assabet is rebooted. Therefore it's possible to automatize the boot
|
||||
time the Assabet is rebooted. Therefore it's possible to automate the boot
|
||||
process using RedBoot's scripting capability.
|
||||
|
||||
For example, I use this to boot Linux with both the kernel and the ramdisk
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
- This file
|
||||
biodoc.txt
|
||||
- Notes on the Generic Block Layer Rewrite in Linux 2.5
|
||||
biovecs.txt
|
||||
- Immutable biovecs and biovec iterators
|
||||
capability.txt
|
||||
- Generic Block Device Capability (/sys/block/<device>/capability)
|
||||
cfq-iosched.txt
|
||||
@@ -14,6 +16,8 @@ deadline-iosched.txt
|
||||
- Deadline IO scheduler tunables
|
||||
ioprio.txt
|
||||
- Block io priorities (in CFQ scheduler)
|
||||
pr.txt
|
||||
- Block layer support for Persistent Reservations
|
||||
null_blk.txt
|
||||
- Null block for block-layer benchmarking.
|
||||
queue-sysfs.txt
|
||||
|
||||
@@ -280,17 +280,9 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally
|
||||
different than user memory, since it can't be swapped out, which makes it
|
||||
possible to DoS the system by consuming too much of this precious resource.
|
||||
|
||||
Kernel memory won't be accounted at all until limit on a group is set. This
|
||||
allows for existing setups to continue working without disruption. The limit
|
||||
cannot be set if the cgroup have children, or if there are already tasks in the
|
||||
cgroup. Attempting to set the limit under those conditions will return -EBUSY.
|
||||
When use_hierarchy == 1 and a group is accounted, its children will
|
||||
automatically be accounted regardless of their limit value.
|
||||
|
||||
After a group is first limited, it will be kept being accounted until it
|
||||
is removed. The memory limitation itself, can of course be removed by writing
|
||||
-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not
|
||||
limited.
|
||||
Kernel memory accounting is enabled for all memory cgroups by default. But
|
||||
it can be disabled system-wide by passing cgroup.memory=nokmem to the kernel
|
||||
at boot time. In this case, kernel memory will not be accounted at all.
|
||||
|
||||
Kernel memory limits are not imposed for the root cgroup. Usage for the root
|
||||
cgroup may or may not be accounted. The memory used is accumulated into
|
||||
|
||||
@@ -186,3 +186,11 @@ only cn_test.c test module used it.
|
||||
Some work in netlink area is still being done, so things can be changed in
|
||||
2.6.15 timeframe, if it will happen, documentation will be updated for that
|
||||
kernel.
|
||||
|
||||
/*****************************************/
|
||||
Code samples
|
||||
/*****************************************/
|
||||
|
||||
Sample code for a connector test module and user space can be found
|
||||
in samples/connector/. To build this code, enable CONFIG_CONNECTOR
|
||||
and CONFIG_SAMPLES.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs
|
||||
|
||||
These devices are audio SoCs with extensive digital capabilites and a range
|
||||
These devices are audio SoCs with extensive digital capabilities and a range
|
||||
of analogue I/O.
|
||||
|
||||
Required properties:
|
||||
|
||||
@@ -268,6 +268,9 @@ IIO
|
||||
devm_iio_trigger_alloc()
|
||||
devm_iio_trigger_free()
|
||||
|
||||
INPUT
|
||||
devm_input_allocate_device()
|
||||
|
||||
IO region
|
||||
devm_release_mem_region()
|
||||
devm_release_region()
|
||||
|
||||
@@ -272,7 +272,7 @@ A partial list of the supported mount options follows:
|
||||
same domain (e.g. running winbind or nss_ldap) and
|
||||
the server supports the Unix Extensions then the uid
|
||||
and gid can be retrieved from the server (and uid
|
||||
and gid would not have to be specifed on the mount.
|
||||
and gid would not have to be specified on the mount.
|
||||
For servers which do not support the CIFS Unix
|
||||
extensions, the default uid (and gid) returned on lookup
|
||||
of existing files will be the uid (gid) of the person
|
||||
|
||||
@@ -29,7 +29,7 @@ Main features of this FS include:
|
||||
* Read request (data read, directory listing, lookup requests) balancing between multiple servers.
|
||||
* Write requests are replicated to multiple servers and completed only when all of them are acked.
|
||||
* Ability to add and/or remove servers from the working set at run-time.
|
||||
* Strong authentification and possible data encryption in network channel.
|
||||
* Strong authentication and possible data encryption in network channel.
|
||||
* Extended attributes support.
|
||||
|
||||
POHMELFS is based on transactions, which are potentially long-standing objects that live
|
||||
|
||||
@@ -16,7 +16,7 @@ qnx6fs shares many properties with traditional Unix filesystems. It has the
|
||||
concepts of blocks, inodes and directories.
|
||||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
for the target (QNX is used on quite a range of embedded systems) platform
|
||||
running on a different endianness.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user