Commit 81a84ad3 authored by Linus Torvalds's avatar Linus Torvalds

Merge branch 'docs-next' of git://git.lwn.net/linux

Pull documentation updates from Jonathan Corbet:
 "After a fair amount of churn in the last couple of cycles, docs are
  taking it easier this time around. Lots of fixes and some new
  documentation, but nothing all that radical. Perhaps the most
  interesting change for many is the scripts/sphinx-pre-install tool
  from Mauro; it will tell you exactly which packages you need to
  install to get a working docs toolchain on your system.

  There are two little patches reaching outside of Documentation/; both
  just tweak kerneldoc comments to eliminate warnings and fix some
  dangling doc pointers"

* 'docs-next' of git://git.lwn.net/linux: (52 commits)
  Documentation/sphinx: fix kernel-doc decode for non-utf-8 locale
  genalloc: Fix an incorrect kerneldoc comment
  doc: Add documentation for the genalloc subsystem
  assoc_array: fix path to assoc_array documentation
  kernel-doc parser mishandles declarations split into lines
  docs: ReSTify table of contents in core.rst
  docs: process: drop git snapshots from applying-patches.rst
  Documentation:input: fix typo
  swap: Remove obsolete sentence
  sphinx.rst: Allow Sphinx version 1.6 at the docs
  docs-rst: fix verbatim font size on tables
  Documentation: stable-kernel-rules: fix broken git urls
  rtmutex: update rt-mutex
  rtmutex: update rt-mutex-design
  docs: fix minimal sphinx version in conf.py
  docs: fix nested numbering in the TOC
  NVMEM documentation fix: A minor typo
  docs-rst: pdf: use same vertical margin on all Sphinx versions
  doc: Makefile: if sphinx is not found, run a check script
  docs: Fix paths in security/keys
  ...
parents fe91f281 86c0f046
...@@ -22,6 +22,8 @@ ifeq ($(HAVE_SPHINX),0) ...@@ -22,6 +22,8 @@ ifeq ($(HAVE_SPHINX),0)
.DEFAULT: .DEFAULT:
$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.) $(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
@echo
@./scripts/sphinx-pre-install
@echo " SKIP Sphinx $@ target." @echo " SKIP Sphinx $@ target."
else # HAVE_SPHINX else # HAVE_SPHINX
...@@ -95,16 +97,6 @@ endif # HAVE_SPHINX ...@@ -95,16 +97,6 @@ endif # HAVE_SPHINX
# The following targets are independent of HAVE_SPHINX, and the rules should # The following targets are independent of HAVE_SPHINX, and the rules should
# work or silently pass without Sphinx. # work or silently pass without Sphinx.
# no-ops for the Sphinx toolchain
sgmldocs:
@:
psdocs:
@:
mandocs:
@:
installmandocs:
@:
cleandocs: cleandocs:
$(Q)rm -rf $(BUILDDIR) $(Q)rm -rf $(BUILDDIR)
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean
......
...@@ -60,7 +60,7 @@ Example of using a firmware operation: ...@@ -60,7 +60,7 @@ Example of using a firmware operation:
/* some platform code, e.g. SMP initialization */ /* some platform code, e.g. SMP initialization */
__raw_writel(virt_to_phys(exynos4_secondary_startup), __raw_writel(__pa_symbol(exynos4_secondary_startup),
CPU1_BOOT_REG); CPU1_BOOT_REG);
/* Call Exynos specific smc call */ /* Call Exynos specific smc call */
......
...@@ -29,7 +29,7 @@ from load_config import loadConfig ...@@ -29,7 +29,7 @@ from load_config import loadConfig
# -- General configuration ------------------------------------------------ # -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here. # If your documentation needs a minimal Sphinx version, state it here.
needs_sphinx = '1.2' needs_sphinx = '1.3'
# Add any Sphinx extension module names here, as strings. They can be # Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
...@@ -344,8 +344,8 @@ if major == 1 and minor > 3: ...@@ -344,8 +344,8 @@ if major == 1 and minor > 3:
if major == 1 and minor <= 4: if major == 1 and minor <= 4:
latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}' latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)): elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=0.5in' latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
latex_elements['preamble'] += '\\fvset{fontsize=auto}\n'
# Grouping the document tree into LaTeX files. List of tuples # Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, # (source start file, target name, title,
......
The genalloc/genpool subsystem
==============================
There are a number of memory-allocation subsystems in the kernel, each
aimed at a specific need. Sometimes, however, a kernel developer needs to
implement a new allocator for a specific range of special-purpose memory;
often that memory is located on a device somewhere. The author of the
driver for that device can certainly write a little allocator to get the
job done, but that is the way to fill the kernel with dozens of poorly
tested allocators. Back in 2005, Jes Sorensen lifted one of those
allocators from the sym53c8xx_2 driver and posted_ it as a generic module
for the creation of ad hoc memory allocators. This code was merged
for the 2.6.13 release; it has been modified considerably since then.
.. _posted: https://lwn.net/Articles/125842/
Code using this allocator should include <linux/genalloc.h>. The action
begins with the creation of a pool using one of:
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_create
.. kernel-doc:: lib/genalloc.c
:functions: devm_gen_pool_create
A call to :c:func:`gen_pool_create` will create a pool. The granularity of
allocations is set with min_alloc_order; it is a log-base-2 number like
those used by the page allocator, but it refers to bytes rather than pages.
So, if min_alloc_order is passed as 3, then all allocations will be a
multiple of eight bytes. Increasing min_alloc_order decreases the memory
required to track the memory in the pool. The nid parameter specifies
which NUMA node should be used for the allocation of the housekeeping
structures; it can be -1 if the caller doesn't care.
The "managed" interface :c:func:`devm_gen_pool_create` ties the pool to a
specific device. Among other things, it will automatically clean up the
pool when the given device is destroyed.
A pool is shut down with:
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_destroy
It's worth noting that, if there are still allocations outstanding from the
given pool, this function will take the rather extreme step of invoking
BUG(), crashing the entire system. You have been warned.
A freshly created pool has no memory to allocate. It is fairly useless in
that state, so one of the first orders of business is usually to add memory
to the pool. That can be done with one of:
.. kernel-doc:: include/linux/genalloc.h
:functions: gen_pool_add
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_add_virt
A call to :c:func:`gen_pool_add` will place the size bytes of memory
starting at addr (in the kernel's virtual address space) into the given
pool, once again using nid as the node ID for ancillary memory allocations.
The :c:func:`gen_pool_add_virt` variant associates an explicit physical
address with the memory; this is only necessary if the pool will be used
for DMA allocations.
The functions for allocating memory from the pool (and putting it back)
are:
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_alloc
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_dma_alloc
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_free
As one would expect, :c:func:`gen_pool_alloc` will allocate size< bytes
from the given pool. The :c:func:`gen_pool_dma_alloc` variant allocates
memory for use with DMA operations, returning the associated physical
address in the space pointed to by dma. This will only work if the memory
was added with :c:func:`gen_pool_add_virt`. Note that this function
departs from the usual genpool pattern of using unsigned long values to
represent kernel addresses; it returns a void * instead.
That all seems relatively simple; indeed, some developers clearly found it
to be too simple. After all, the interface above provides no control over
how the allocation functions choose which specific piece of memory to
return. If that sort of control is needed, the following functions will be
of interest:
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_alloc_algo
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_set_algo
Allocations with :c:func:`gen_pool_alloc_algo` specify an algorithm to be
used to choose the memory to be allocated; the default algorithm can be set
with :c:func:`gen_pool_set_algo`. The data value is passed to the
algorithm; most ignore it, but it is occasionally needed. One can,
naturally, write a special-purpose algorithm, but there is a fair set
already available:
- gen_pool_first_fit is a simple first-fit allocator; this is the default
algorithm if none other has been specified.
- gen_pool_first_fit_align forces the allocation to have a specific
alignment (passed via data in a genpool_data_align structure).
- gen_pool_first_fit_order_align aligns the allocation to the order of the
size. A 60-byte allocation will thus be 64-byte aligned, for example.
- gen_pool_best_fit, as one would expect, is a simple best-fit allocator.
- gen_pool_fixed_alloc allocates at a specific offset (passed in a
genpool_data_fixed structure via the data parameter) within the pool.
If the indicated memory is not available the allocation fails.
There is a handful of other functions, mostly for purposes like querying
the space available in the pool or iterating through chunks of memory.
Most users, however, should not need much beyond what has been described
above. With luck, wider awareness of this module will help to prevent the
writing of special-purpose memory allocators in the future.
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_virt_to_phys
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_for_each_chunk
.. kernel-doc:: lib/genalloc.c
:functions: addr_in_gen_pool
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_avail
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_size
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_get
.. kernel-doc:: lib/genalloc.c
:functions: of_gen_pool_get
...@@ -20,6 +20,7 @@ Core utilities ...@@ -20,6 +20,7 @@ Core utilities
genericirq genericirq
flexible-arrays flexible-arrays
librs librs
genalloc
Interfaces for kernel debugging Interfaces for kernel debugging
=============================== ===============================
......
...@@ -31,11 +31,13 @@ Setup ...@@ -31,11 +31,13 @@ Setup
CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
CONFIG_FRAME_POINTER, keep it enabled. CONFIG_FRAME_POINTER, keep it enabled.
- Install that kernel on the guest. - Install that kernel on the guest, turn off KASLR if necessary by adding
"nokaslr" to the kernel command line.
Alternatively, QEMU allows to boot the kernel directly using -kernel, Alternatively, QEMU allows to boot the kernel directly using -kernel,
-append, -initrd command line switches. This is generally only useful if -append, -initrd command line switches. This is generally only useful if
you do not depend on modules. See QEMU documentation for more details on you do not depend on modules. See QEMU documentation for more details on
this mode. this mode. In this case, you should build the kernel with
CONFIG_RANDOMIZE_BASE disabled if the architecture supports KASLR.
- Enable the gdb stub of QEMU/KVM, either - Enable the gdb stub of QEMU/KVM, either
......
...@@ -348,6 +348,15 @@ default behavior is always set to 0. ...@@ -348,6 +348,15 @@ default behavior is always set to 0.
- ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot`` - ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot``
- Enter the debugger on reboot notify. - Enter the debugger on reboot notify.
Kernel parameter: ``nokaslr``
-----------------------------
If the architecture that you are using enable KASLR by default,
you should consider turning it off. KASLR randomizes the
virtual address where the kernel image is mapped and confuse
gdb which resolve kernel symbol address from symbol table
of vmlinux.
Using kdb Using kdb
========= =========
...@@ -358,7 +367,7 @@ This is a quick example of how to use kdb. ...@@ -358,7 +367,7 @@ This is a quick example of how to use kdb.
1. Configure kgdboc at boot using kernel parameters:: 1. Configure kgdboc at boot using kernel parameters::
console=ttyS0,115200 kgdboc=ttyS0,115200 console=ttyS0,115200 kgdboc=ttyS0,115200 nokaslr
OR OR
......
...@@ -19,6 +19,110 @@ Finally, there are thousands of plain text documentation files scattered around ...@@ -19,6 +19,110 @@ Finally, there are thousands of plain text documentation files scattered around
``Documentation``. Some of these will likely be converted to reStructuredText ``Documentation``. Some of these will likely be converted to reStructuredText
over time, but the bulk of them will remain in plain text. over time, but the bulk of them will remain in plain text.
.. _sphinx_install:
Sphinx Install
==============
The ReST markups currently used by the Documentation/ files are meant to be
built with ``Sphinx`` version 1.3 or upper. If you're desiring to build
PDF outputs, it is recommended to use version 1.4.6 or upper.
There's a script that checks for the Spinx requirements. Please see
:ref:`sphinx-pre-install` for further details.
Most distributions are shipped with Sphinx, but its toolchain is fragile,
and it is not uncommon that upgrading it or some other Python packages
on your machine would cause the documentation build to break.
A way to get rid of that is to use a different version than the one shipped
on your distributions. In order to do that, it is recommended to install
Sphinx inside a virtual environment, using ``virtualenv-3``
or ``virtualenv``, depending on how your distribution packaged Python 3.
.. note::
#) Sphinx versions below 1.5 don't work properly with Python's
docutils version 0.13.1 or upper. So, if you're willing to use
those versions, you should run ``pip install 'docutils==0.12'``.
#) It is recommended to use the RTD theme for html output. Depending
on the Sphinx version, it should be installed in separate,
with ``pip install sphinx_rtd_theme``.
#) Some ReST pages contain math expressions. Due to the way Sphinx work,
those expressions are written using LaTeX notation. It needs texlive
installed with amdfonts and amsmath in order to evaluate them.
In summary, if you want to install Sphinx version 1.4.9, you should do::
$ virtualenv sphinx_1.4
$ . sphinx_1.4/bin/activate
(sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt
After running ``. sphinx_1.4/bin/activate``, the prompt will change,
in order to indicate that you're using the new environment. If you
open a new shell, you need to rerun this command to enter again at
the virtual environment before building the documentation.
Image output
------------
The kernel documentation build system contains an extension that
handles images on both GraphViz and SVG formats (see
:ref:`sphinx_kfigure`).
For it to work, you need to install both GraphViz and ImageMagick
packages. If those packages are not installed, the build system will
still build the documentation, but won't include any images at the
output.
PDF and LaTeX builds
--------------------
Such builds are currently supported only with Sphinx versions 1.4 and upper.
For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265.
Depending on the distribution, you may also need to install a series of
``texlive`` packages that provide the minimal set of functionalities
required for ``XeLaTeX`` to work.
.. _sphinx-pre-install:
Checking for Sphinx dependencies
--------------------------------
There's a script that automatically check for Sphinx dependencies. If it can
recognize your distribution, it will also give a hint about the install
command line options for your distro::
$ ./scripts/sphinx-pre-install
Checking if the needed tools for Fedora release 26 (Twenty Six) are available
Warning: better to also install "texlive-luatex85".
You should run:
sudo dnf install -y texlive-luatex85
/usr/bin/virtualenv sphinx_1.4
. sphinx_1.4/bin/activate
pip install -r Documentation/sphinx/requirements.txt
Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468.
By default, it checks all the requirements for both html and PDF, including
the requirements for images, math expressions and LaTeX build, and assumes
that a virtual Python environment will be used. The ones needed for html
builds are assumed to be mandatory; the others to be optional.
It supports two optional parameters:
``--no-pdf``
Disable checks for PDF;
``--no-virtualenv``
Use OS packaging for Sphinx instead of Python virtual environment.
Sphinx Build Sphinx Build
============ ============
...@@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation: ...@@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation:
the C domain the C domain
------------ ------------
The `Sphinx C Domain`_ (name c) is suited for documentation of C API. E.g. a The **Sphinx C Domain** (name c) is suited for documentation of C API. E.g. a
function prototype: function prototype:
.. code-block:: rst .. code-block:: rst
...@@ -229,6 +333,7 @@ Rendered as: ...@@ -229,6 +333,7 @@ Rendered as:
- column 3 - column 3
.. _sphinx_kfigure:
Figures & Images Figures & Images
================ ================
......
...@@ -4,7 +4,7 @@ Driver Basics ...@@ -4,7 +4,7 @@ Driver Basics
Driver Entry and Exit points Driver Entry and Exit points
---------------------------- ----------------------------
.. kernel-doc:: include/linux/init.h .. kernel-doc:: include/linux/module.h
:internal: :internal:
Driver device table Driver device table
...@@ -103,9 +103,6 @@ Kernel utility functions ...@@ -103,9 +103,6 @@ Kernel utility functions
.. kernel-doc:: kernel/panic.c .. kernel-doc:: kernel/panic.c
:export: :export:
.. kernel-doc:: kernel/sys.c
:export:
.. kernel-doc:: kernel/rcu/tree.c .. kernel-doc:: kernel/rcu/tree.c
:export: :export:
......
...@@ -139,9 +139,6 @@ DMA Fences ...@@ -139,9 +139,6 @@ DMA Fences
Seqno Hardware Fences Seqno Hardware Fences
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/dma-buf/seqno-fence.c
:export:
.. kernel-doc:: include/linux/seqno-fence.h .. kernel-doc:: include/linux/seqno-fence.h
:internal: :internal:
......
...@@ -47,4 +47,3 @@ used by one consumer at a time. ...@@ -47,4 +47,3 @@ used by one consumer at a time.
.. kernel-doc:: drivers/pwm/core.c .. kernel-doc:: drivers/pwm/core.c
:export: :export:
...@@ -75,7 +75,7 @@ The channel-measurement facility provides a means to collect measurement ...@@ -75,7 +75,7 @@ The channel-measurement facility provides a means to collect measurement
data which is made available by the channel subsystem for each channel data which is made available by the channel subsystem for each channel
attached device. attached device.
.. kernel-doc:: arch/s390/include/asm/cmb.h .. kernel-doc:: arch/s390/include/uapi/asm/cmb.h
:internal: :internal:
.. kernel-doc:: drivers/s390/cio/cmf.c .. kernel-doc:: drivers/s390/cio/cmf.c
......
...@@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface ...@@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface
.. kernel-doc:: drivers/scsi/hosts.c .. kernel-doc:: drivers/scsi/hosts.c
:export: :export:
drivers/scsi/constants.c
~~~~~~~~~~~~~~~~~~~~~~~~
mid to lowlevel SCSI driver interface
.. kernel-doc:: drivers/scsi/constants.c
:export:
Transport classes Transport classes
----------------- -----------------
......
...@@ -25,7 +25,7 @@ ...@@ -25,7 +25,7 @@
| mn10300: | ok | | mn10300: | ok |
| nios2: | ok | | nios2: | ok |
| openrisc: | ok | | openrisc: | ok |
| parisc: | TODO | | parisc: | ok |
| powerpc: | ok | | powerpc: | ok |
| s390: | ok | | s390: | ok |
| score: | TODO | | score: | TODO |
......
...@@ -829,9 +829,7 @@ struct address_space_operations { ...@@ -829,9 +829,7 @@ struct address_space_operations {
swap_activate: Called when swapon is used on a file to allocate swap_activate: Called when swapon is used on a file to allocate
space if necessary and pin the block lookup information in space if necessary and pin the block lookup information in
memory. A return value of zero indicates success, memory. A return value of zero indicates success,
in which case this file can be used to back swapspace. The in which case this file can be used to back swapspace.
swapspace operations will be proxied to this address space's
->swap_{out,in} methods.
swap_deactivate: Called during swapoff on files where swap_activate swap_deactivate: Called during swapoff on files where swap_activate
was successful. was successful.
......
...@@ -109,7 +109,7 @@ evdev nodes are created with minors starting with 256. ...@@ -109,7 +109,7 @@ evdev nodes are created with minors starting with 256.
keyboard keyboard
~~~~~~~~ ~~~~~~~~
``keyboard`` is in-kernel input handler ad is a part of VT code. It ``keyboard`` is in-kernel input handler and is a part of VT code. It
consumes keyboard keystrokes and handles user input for VT consoles. consumes keyboard keystrokes and handles user input for VT consoles.
mousedev mousedev
......
...@@ -12,7 +12,6 @@ Linux Joystick support ...@@ -12,7 +12,6 @@ Linux Joystick support
.. toctree:: .. toctree::
:maxdepth: 3 :maxdepth: 3
:numbered:
joystick joystick
joystick-api joystick-api
...@@ -297,8 +297,8 @@ more details, with real examples. ...@@ -297,8 +297,8 @@ more details, with real examples.
ccflags-y specifies options for compiling with $(CC). ccflags-y specifies options for compiling with $(CC).
Example: Example:
# drivers/acpi/Makefile # drivers/acpi/acpica/Makefile
ccflags-y := -Os ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
This variable is necessary because the top Makefile owns the This variable is necessary because the top Makefile owns the
......
This diff is collapsed.
...@@ -28,14 +28,13 @@ magic bullet for poorly designed applications, but it allows ...@@ -28,14 +28,13 @@ magic bullet for poorly designed applications, but it allows
well-designed applications to use userspace locks in critical parts of well-designed applications to use userspace locks in critical parts of
an high priority thread, without losing determinism. an high priority thread, without losing determinism.
The enqueueing of the waiters into the rtmutex waiter list is done in The enqueueing of the waiters into the rtmutex waiter tree is done in
priority order. For same priorities FIFO order is chosen. For each priority order. For same priorities FIFO order is chosen. For each
rtmutex, only the top priority waiter is enqueued into the owner's rtmutex, only the top priority waiter is enqueued into the owner's
priority waiters list. This list too queues in priority order. Whenever priority waiters tree. This tree too queues in priority order. Whenever
the top priority waiter of a task changes (for example it timed out or the top priority waiter of a task changes (for example it timed out or
got a signal), the priority of the owner task is readjusted. [The got a signal), the priority of the owner task is readjusted. The
priority enqueueing is handled by "plists", see include/linux/plist.h priority enqueueing is handled by "pi_waiters".
for more details.]
RT-mutexes are optimized for fastpath operations and have no internal RT-mutexes are optimized for fastpath operations and have no internal
locking overhead when locking an uncontended mutex or unlocking a mutex locking overhead when locking an uncontended mutex or unlocking a mutex
...@@ -46,34 +45,29 @@ is used] ...@@ -46,34 +45,29 @@ is used]
The state of the rt-mutex is tracked via the owner field of the rt-mutex The state of the rt-mutex is tracked via the owner field of the rt-mutex
structure: structure:
rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1 lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
are used to keep track of the "owner is pending" and "rtmutex has keep track of the "lock has waiters" state.
waiters" state.
owner bit1 bit0 owner bit0
NULL 0 0 mutex is free (fast acquire possible) NULL 0 lock is free (fast acquire possible)
NULL 0 1 invalid state NULL 1 lock is free and has waiters and the top waiter
NULL 1 0 Transitional state* is going to take the lock*
NULL 1 1 invalid state taskpointer 0 lock is held (fast release possible)
taskpointer 0 0 mutex is held (fast release possible) taskpointer 1 lock is held and has waiters**
taskpointer 0 1 task is pending owner
taskpointer 1 0 mutex is held and has waiters
taskpointer 1 1 task is pending owner and mutex has waiters
Pending-ownership handling is a performance optimization: The fast atomic compare exchange based acquire and release is only
pending-ownership is assigned to the first (highest priority) waiter of possible when bit 0 of lock->owner is 0.
the mutex, when the mutex is released. The thread is woken up and once
it starts executing it can acquire the mutex. Until the mutex is taken
by it (bit 0 is cleared) a competing higher priority thread can "steal"
the mutex which puts the woken up thread back on the waiters list.
The pending-ownership optimization is especially important for the (*) It also can be a transitional state when grabbing the lock
uninterrupted workflow of high-prio tasks which repeatedly with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
takes/releases locks that have lower-prio waiters. Without this we need to set the bit0 before looking at the lock, and the owner may be
optimization the higher-prio thread would ping-pong to the lower-prio NULL in this small time, hence this can be a transitional state.
task [because at unlock time we always assign a new owner].
(*) The "mutex has waiters" bit gets set to take the lock. If the lock (**) There is a small time when bit 0 is set but there are no
doesn't already have an owner, this bit is quickly cleared if there are waiters. This can happen when grabbing the lock in the slow path.
no waiters. So this is a transitional state to synchronize with looking To prevent a cmpxchg of the owner releasing the lock, we need to
at the owner field of the mutex and the mutex owner releasing the lock. set this bit before looking at the lock.
BTW, there is still technically a "Pending Owner", it's just not called
that anymore. The pending owner happens to be the top_waiter of a lock
that has no owner and has been woken up to grab the lock.
...@@ -7,7 +7,6 @@ Function Reference ...@@ -7,7 +7,6 @@ Function Reference
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
:numbered:
cec-func-open cec-func-open
cec-func-close cec-func-close
......
...@@ -84,17 +84,17 @@ Device drivers API ...@@ -84,17 +84,17 @@ Device drivers API
================== ==================
The include/net/mac802154.h defines following functions: The include/net/mac802154.h defines following functions:
- struct ieee802154_dev *ieee802154_alloc_device - struct ieee802154_hw *
(size_t priv_size, struct ieee802154_ops *ops): ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops):
allocation of IEEE 802.15.4 compatible device allocation of IEEE 802.15.4 compatible hardware device
- void ieee802154_free_device(struct ieee802154_dev *dev): - void ieee802154_free_hw(struct ieee802154_hw *hw):
freeing allocated device freeing allocated hardware device
- int ieee802154_register_device(struct ieee802154_dev *dev): - int ieee802154_register_hw(struct ieee802154_hw *hw):
register PHY in the system register PHY which is the allocated hardware device, in the system
- void ieee802154_unregister_device(struct ieee802154_dev *dev): - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
freeing registered PHY freeing registered PHY
Moreover IEEE 802.15.4 device operations structure should be filled. Moreover IEEE 802.15.4 device operations structure should be filled.
......
...@@ -112,7 +112,7 @@ take nvmem_device as parameter. ...@@ -112,7 +112,7 @@ take nvmem_device as parameter.
5. Releasing a reference to the NVMEM 5. Releasing a reference to the NVMEM
===================================== =====================================
When a consumers no longer needs the NVMEM, it has to release the reference When a consumer no longer needs the NVMEM, it has to release the reference
to the NVMEM it has obtained using the APIs mentioned in the above section. to the NVMEM it has obtained using the APIs mentioned in the above section.
The NVMEM framework provides 2 APIs to release a reference to the NVMEM. The NVMEM framework provides 2 APIs to release a reference to the NVMEM.
......
...@@ -6,9 +6,6 @@ Applying Patches To The Linux Kernel ...@@ -6,9 +6,6 @@ Applying Patches To The Linux Kernel
Original by: Original by:
Jesper Juhl, August 2005 Jesper Juhl, August 2005
Last update:
2016-09-14
.. note:: .. note::
This document is obsolete. In most cases, rather than using ``patch`` This document is obsolete. In most cases, rather than using ``patch``
...@@ -344,7 +341,7 @@ possible. ...@@ -344,7 +341,7 @@ possible.
This is a good branch to run for people who want to help out testing This is a good branch to run for people who want to help out testing
development kernels but do not want to run some of the really experimental development kernels but do not want to run some of the really experimental
stuff (such people should see the sections about -git and -mm kernels below). stuff (such people should see the sections about -next and -mm kernels below).
The -rc patches are not incremental, they apply to a base 4.x kernel, just The -rc patches are not incremental, they apply to a base 4.x kernel, just
like the 4.x.y patches described above. The kernel version before the -rcN like the 4.x.y patches described above. The kernel version before the -rcN
...@@ -380,44 +377,6 @@ Here are 3 examples of how to apply these patches:: ...@@ -380,44 +377,6 @@ Here are 3 examples of how to apply these patches::
$ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir $ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir
The -git kernels
================
These are daily snapshots of Linus' kernel tree (managed in a git
repository, hence the name).
These patches are usually released daily and represent the current state of
Linus's tree. They are more experimental than -rc kernels since they are
generated automatically without even a cursory glance to see if they are
sane.
-git patches are not incremental and apply either to a base 4.x kernel or
a base 4.x-rc kernel -- you can see which from their name.
A patch named 4.7-git1 applies to the 4.7 kernel source and a patch
named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel.
Here are some examples of how to apply these patches::
# moving from 4.7 to 4.7-git1
$ cd ~/linux-4.7 # change to the kernel source dir
$ patch -p1 < ../patch-4.7-git1 # apply the 4.7-git1 patch
$ cd ..
$ mv linux-4.7 linux-4.7-git1 # rename the kernel source dir
# moving from 4.7-git1 to 4.8-rc2-git3
$ cd ~/linux-4.7-git1 # change to the kernel source dir
$ patch -p1 -R < ../patch-4.7-git1 # revert the 4.7-git1 patch
# we now have a 4.7 kernel
$ patch -p1 < ../patch-4.8-rc2 # apply the 4.8-rc2 patch
# the kernel is now 4.8-rc2
$ patch -p1 < ../patch-4.8-rc2-git3 # apply the 4.8-rc2-git3 patch
# the kernel is now 4.8-rc2-git3
$ cd ..
$ mv linux-4.7-git1 linux-4.8-rc2-git3 # rename source dir
The -mm patches and the linux-next tree The -mm patches and the linux-next tree
======================================= =======================================
......
...@@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version ...@@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version
iptables 1.4.2 iptables -V iptables 1.4.2 iptables -V
openssl & libcrypto 1.0.0 openssl version openssl & libcrypto 1.0.0 openssl version
bc 1.06.95 bc --version bc 1.06.95 bc --version
Sphinx\ [#f1]_ 1.2 sphinx-build --version Sphinx\ [#f1]_ 1.3 sphinx-build --version
====================== =============== ======================================== ====================== =============== ========================================
.. [#f1] Sphinx is needed only to build the Kernel documentation .. [#f1] Sphinx is needed only to build the Kernel documentation
...@@ -309,18 +309,8 @@ Kernel documentation ...@@ -309,18 +309,8 @@ Kernel documentation
Sphinx Sphinx
------ ------
The ReST markups currently used by the Documentation/ files are meant to be Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst``
built with ``Sphinx`` version 1.2 or upper. If you're desiring to build for details about Sphinx requirements.
PDF outputs, it is recommended to use version 1.4.6.
.. note::
Please notice that, for PDF and LaTeX output, you'll also need ``XeLaTeX``
version 3.14159265. Depending on the distribution, you may also need to
install a series of ``texlive`` packages that provide the minimal set of
functionalities required for ``XeLaTex`` to work. For PDF output you'll also
need ``convert(1)`` from ImageMagick (https://www.imagemagick.org).
Getting updated software Getting updated software
======================== ========================
......
...@@ -166,12 +166,12 @@ Trees ...@@ -166,12 +166,12 @@ Trees
- The queues of patches, for both completed versions and in progress - The queues of patches, for both completed versions and in progress
versions can be found at: versions can be found at:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
- The finalized and tagged releases of all stable kernels can be found - The finalized and tagged releases of all stable kernels can be found
in separate branches per version at: in separate branches per version at:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Review committee Review committee
......
...@@ -413,7 +413,7 @@ e-mail discussions. ...@@ -413,7 +413,7 @@ e-mail discussions.
11) Sign your work the Developer's Certificate of Origin 11) Sign your work - the Developer's Certificate of Origin
---------------------------------------------------------- ----------------------------------------------------------
To improve tracking of who did what, especially with patches that can To improve tracking of who did what, especially with patches that can
......
...@@ -16,17 +16,7 @@ The key service can be configured on by enabling: ...@@ -16,17 +16,7 @@ The key service can be configured on by enabling:
This document has the following sections: This document has the following sections:
- Key overview .. contents:: :local:
- Key service overview
- Key access permissions
- SELinux support
- New procfs files
- Userspace system call interface
- Kernel services
- Notes on accessing payload contents
- Defining a key type
- Request-key callback service
- Garbage collection
Key Overview Key Overview
...@@ -443,7 +433,7 @@ The main syscalls are: ...@@ -443,7 +433,7 @@ The main syscalls are:
/sbin/request-key will be invoked in an attempt to obtain a key. The /sbin/request-key will be invoked in an attempt to obtain a key. The
callout_info string will be passed as an argument to the program. callout_info string will be passed as an argument to the program.
See also Documentation/security/keys-request-key.txt. See also Documentation/security/keys/request-key.rst.
The keyctl syscall functions are: The keyctl syscall functions are:
...@@ -973,7 +963,7 @@ payload contents" for more information. ...@@ -973,7 +963,7 @@ payload contents" for more information.
If successful, the key will have been attached to the default keyring for If successful, the key will have been attached to the default keyring for
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
See also Documentation/security/keys-request-key.txt. See also Documentation/security/keys/request-key.rst.
* To search for a key, passing auxiliary data to the upcaller, call:: * To search for a key, passing auxiliary data to the upcaller, call::
......
...@@ -3,7 +3,7 @@ Key Request Service ...@@ -3,7 +3,7 @@ Key Request Service
=================== ===================
The key request service is part of the key retention service (refer to The key request service is part of the key retention service (refer to
Documentation/security/keys.txt). This document explains more fully how Documentation/security/core.rst). This document explains more fully how
the requesting algorithm works. the requesting algorithm works.
The process starts by either the kernel requesting a service by calling The process starts by either the kernel requesting a service by calling
......
...@@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk and file encryption ...@@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk and file encryption
are anticipated. In particular the new format 'ecryptfs' has been defined in are anticipated. In particular the new format 'ecryptfs' has been defined in
in order to use encrypted keys to mount an eCryptfs filesystem. More details in order to use encrypted keys to mount an eCryptfs filesystem. More details
about the usage can be found in the file about the usage can be found in the file
``Documentation/security/keys-ecryptfs.txt``. ``Documentation/security/keys/ecryptfs.rst``.
...@@ -4,6 +4,17 @@ ...@@ -4,6 +4,17 @@
* *
*/ */
/* Interim: Code-blocks with line nos - lines and line numbers don't line up.
* see: https://github.com/rtfd/sphinx_rtd_theme/issues/419
*/
div[class^="highlight"] pre {
line-height: normal;
}
.rst-content .highlight > pre {
line-height: normal;
}
@media screen { @media screen {
/* content column /* content column
...@@ -56,6 +67,12 @@ ...@@ -56,6 +67,12 @@
font-family: "Courier New", Courier, monospace font-family: "Courier New", Courier, monospace
} }
/* fix bottom margin of lists items */
.rst-content .section ul li:last-child, .rst-content .section ul li p:last-child {
margin-bottom: 12px;
}
/* inline literal: drop the borderbox, padding and red color */ /* inline literal: drop the borderbox, padding and red color */
code, .rst-content tt, .rst-content code { code, .rst-content tt, .rst-content code {
......
...@@ -27,6 +27,7 @@ ...@@ -27,6 +27,7 @@
# Please make sure this works on both python2 and python3. # Please make sure this works on both python2 and python3.
# #
import codecs
import os import os
import subprocess import subprocess
import sys import sys
...@@ -88,13 +89,10 @@ class KernelDocDirective(Directive): ...@@ -88,13 +89,10 @@ class KernelDocDirective(Directive):
try: try:
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd))) env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True) p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
out, err = p.communicate() out, err = p.communicate()
# python2 needs conversion to unicode. out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
# python3 with universal_newlines=True returns strings.
if sys.version_info.major < 3:
out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
if p.returncode != 0: if p.returncode != 0:
sys.stderr.write(err) sys.stderr.write(err)
......
docutils==0.12
Sphinx==1.4.9
sphinx_rtd_theme
...@@ -149,9 +149,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 ...@@ -149,9 +149,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册 核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册
页等不同格式的文档: 页等不同格式的文档:
make pdfdocs make pdfdocs
make psdocs
make htmldocs make htmldocs
make mandocs
如何成为内核开发者 如何成为内核开发者
......
...@@ -1468,7 +1468,7 @@ $(help-board-dirs): help-%: ...@@ -1468,7 +1468,7 @@ $(help-board-dirs): help-%:
# Documentation targets # Documentation targets
# --------------------------------------------------------------------------- # ---------------------------------------------------------------------------
DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs installmandocs epubdocs cleandocs linkcheckdocs DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs linkcheckdocs
PHONY += $(DOC_TARGETS) PHONY += $(DOC_TARGETS)
$(DOC_TARGETS): scripts_basic FORCE $(DOC_TARGETS): scripts_basic FORCE
$(Q)$(MAKE) $(build)=Documentation $@ $(Q)$(MAKE) $(build)=Documentation $@
......
...@@ -38,12 +38,13 @@ struct device_node; ...@@ -38,12 +38,13 @@ struct device_node;
struct gen_pool; struct gen_pool;
/** /**
* Allocation callback function type definition * typedef genpool_algo_t: Allocation callback function type definition
* @map: Pointer to bitmap * @map: Pointer to bitmap
* @size: The bitmap size in bits * @size: The bitmap size in bits
* @start: The bitnumber to start searching at * @start: The bitnumber to start searching at
* @nr: The number of zeroed bits we're looking for * @nr: The number of zeroed bits we're looking for
* @data: optional additional data used by @genpool_algo_t * @data: optional additional data used by the callback
* @pool: the pool being allocated from
*/ */
typedef unsigned long (*genpool_algo_t)(unsigned long *map, typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size, unsigned long size,
......
/* Generic associative array implementation. /* Generic associative array implementation.
* *
* See Documentation/assoc_array.txt for information. * See Documentation/core-api/assoc_array.rst for information.
* *
* Copyright (C) 2013 Red Hat, Inc. All Rights Reserved. * Copyright (C) 2013 Red Hat, Inc. All Rights Reserved.
* Written by David Howells (dhowells@redhat.com) * Written by David Howells (dhowells@redhat.com)
......
...@@ -2226,6 +2226,7 @@ sub dump_enum($$) { ...@@ -2226,6 +2226,7 @@ sub dump_enum($$) {
if ($x =~ /enum\s+(\w+)\s*{(.*)}/) { if ($x =~ /enum\s+(\w+)\s*{(.*)}/) {
$declaration_name = $1; $declaration_name = $1;
my $members = $2; my $members = $2;
$members =~ s/\s+$//;
foreach my $arg (split ',', $members) { foreach my $arg (split ',', $members) {
$arg =~ s/^\s*(\w+).*/$1/; $arg =~ s/^\s*(\w+).*/$1/;
...@@ -2766,6 +2767,9 @@ sub process_proto_type($$) { ...@@ -2766,6 +2767,9 @@ sub process_proto_type($$) {
while (1) { while (1) {
if ( $x =~ /([^{};]*)([{};])(.*)/ ) { if ( $x =~ /([^{};]*)([{};])(.*)/ ) {
if( length $prototype ) {
$prototype .= " "
}
$prototype .= $1 . $2; $prototype .= $1 . $2;
($2 eq '{') && $brcount++; ($2 eq '{') && $brcount++;
($2 eq '}') && $brcount--; ($2 eq '}') && $brcount--;
......
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment