mirror of
https://github.com/a52xq-dev/kernel.git
synced 2026-10-18 21:58:11 +07:00
Documentation updates for 4.16. New stuff includes refcount_t
documentation, errseq documentation, kernel-doc support for nested structure definitions, the removal of lots of crufty kernel-doc support for unused formats, SPDX tag documentation, the beginnings of a manual for subsystem maintainers, and lots of fixes and updates. As usual, some of the changesets reach outside of Documentation/ to effect kerneldoc comment fixes. It also adds the new LICENSES directory, of which Thomas promises I do not need to be the maintainer. -----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJab11TAAoJEI3ONVYwIuV6i1UP/1LgGPHW9Ygq5qaLFbReZd/u Mx/orrhHX0PdkbCCE+CbL8Vm1m4UKFDTBdlpk3s542zxeeG0ZBXuTnvq4Kyk+cTN p4/vsIEzk/Ih13/glGE5MlV+EjiEK+8hK69TIUj7bAyuHmpzofjRz9/1M6RLDGDC HY6UI58AXG0yOQWMWCGRMYpQAFUGij2equ7Doe1ugXRq14dx7V4RsOhI140iRk7t bquAq1rS2fXniiuPFmLBUe4dWW28isVa/Vl/aXcaWQDKMyT0OLhjOMW36wWKqtPi WdVCpHv1NLZNyZZr9S3kvfOwW+BUqpEzfVwssyBLW4h0tsnIx0U0HVhSTY8/TvFZ QD9yCSana4LB/e5CHXIX5lBHbjHxf+rETXqVV4MgwDaMvM3mCo4X6WUTJDmZADo6 vQISEKeb4su5uWAbc9T9xwRSLhZnFVdJ/QuYdNQ5+EpFJYLhzQ9eBvEz6JstSIXL p9ASBiPNY3ulpVZ8q0JOHJRBhq5mHJH6Dy8achzbILy2l/ZI4b8lJ53mw9II04cp puF96E6HpvuZ8Tgjjrg9U3ZdxXNrUgc/tjk2ZDkyTglk1XF2jKSq2tiNSZ3oLrJm XqJPnpCeyJM5UDvwkIBzgC41WEHwe8uvoNbUnc4X7UJSZegFzcSLQXf5qaprHS5k XeQ7sbd+S+jzVVjFi0W5 =Z15Z -----END PGP SIGNATURE----- Merge tag 'docs-4.16' of git://git.lwn.net/linux Pull documentation updates from Jonathan Corbet: "Documentation updates for 4.16. New stuff includes refcount_t documentation, errseq documentation, kernel-doc support for nested structure definitions, the removal of lots of crufty kernel-doc support for unused formats, SPDX tag documentation, the beginnings of a manual for subsystem maintainers, and lots of fixes and updates. As usual, some of the changesets reach outside of Documentation/ to effect kerneldoc comment fixes. It also adds the new LICENSES directory, of which Thomas promises I do not need to be the maintainer" * tag 'docs-4.16' of git://git.lwn.net/linux: (65 commits) linux-next: docs-rst: Fix typos in kfigure.py linux-next: DOC: HWPOISON: Fix path to debugfs in hwpoison.txt Documentation: Fix misconversion of #if docs: add index entry for networking/msg_zerocopy Documentation: security/credentials.rst: explain need to sort group_list LICENSES: Add MPL-1.1 license LICENSES: Add the GPL 1.0 license LICENSES: Add Linux syscall note exception LICENSES: Add the MIT license LICENSES: Add the BSD-3-clause "Clear" license LICENSES: Add the BSD 3-clause "New" or "Revised" License LICENSES: Add the BSD 2-clause "Simplified" license LICENSES: Add the LGPL-2.1 license LICENSES: Add the LGPL 2.0 license LICENSES: Add the GPL 2.0 license Documentation: Add license-rules.rst to describe how to properly identify file licenses scripts: kernel_doc: better handle show warnings logic fs/*/Kconfig: drop links to 404-compliant http://acl.bestbits.at doc: md: Fix a file name to md-fault.c in fault-injection.txt errseq: Add to documentation tree ...
This commit is contained in:
Linus Torvalds
commit
255442c938
67 changed files with 3887 additions and 2006 deletions
|
|
@ -228,8 +228,6 @@ isdn/
|
|||
- directory with info on the Linux ISDN support, and supported cards.
|
||||
kbuild/
|
||||
- directory with info about the kernel build process.
|
||||
kernel-doc-nano-HOWTO.txt
|
||||
- outdated info about kernel-doc documentation.
|
||||
kdump/
|
||||
- directory with mini HowTo on getting the crash dump code to work.
|
||||
doc-guide/
|
||||
|
|
@ -346,8 +344,6 @@ prctl/
|
|||
- directory with info on the priveledge control subsystem
|
||||
preempt-locking.txt
|
||||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
process/
|
||||
- how to work with the mainline kernel development process.
|
||||
pps/
|
||||
|
|
|
|||
|
|
@ -2538,6 +2538,9 @@
|
|||
This is useful when you use a panic=... timeout and
|
||||
need the box quickly up again.
|
||||
|
||||
These settings can be accessed at runtime via
|
||||
the nmi_watchdog and hardlockup_panic sysctls.
|
||||
|
||||
netpoll.carrier_timeout=
|
||||
[NET] Specifies amount of time (in seconds) that
|
||||
netpoll should wait for a carrier. By default netpoll
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ This will allow you to execute Mono-based .NET binaries just like any
|
|||
other program after you have done the following:
|
||||
|
||||
1) You MUST FIRST install the Mono CLR support, either by downloading
|
||||
a binary package, a source tarball or by installing from CVS. Binary
|
||||
a binary package, a source tarball or by installing from Git. Binary
|
||||
packages for several distributions can be found at:
|
||||
|
||||
http://go-mono.com/download.html
|
||||
http://www.mono-project.com/download/
|
||||
|
||||
Instructions for compiling Mono can be found at:
|
||||
|
||||
http://www.go-mono.com/compiling.html
|
||||
http://www.mono-project.com/docs/compiling-mono/linux/
|
||||
|
||||
Once the Mono CLR support has been installed, just check that
|
||||
``/usr/bin/mono`` (which could be located elsewhere, for example
|
||||
|
|
|
|||
|
|
@ -88,7 +88,6 @@ finally:
|
|||
if makefile_version and makefile_patchlevel:
|
||||
version = release = makefile_version + '.' + makefile_patchlevel
|
||||
else:
|
||||
sys.stderr.write('Warning: Could not extract kernel version\n')
|
||||
version = release = "unknown version"
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
|
|
|
|||
159
Documentation/core-api/errseq.rst
Normal file
159
Documentation/core-api/errseq.rst
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
=====================
|
||||
The errseq_t datatype
|
||||
=====================
|
||||
|
||||
An errseq_t is a way of recording errors in one place, and allowing any
|
||||
number of "subscribers" to tell whether it has changed since a previous
|
||||
point where it was sampled.
|
||||
|
||||
The initial use case for this is tracking errors for file
|
||||
synchronization syscalls (fsync, fdatasync, msync and sync_file_range),
|
||||
but it may be usable in other situations.
|
||||
|
||||
It's implemented as an unsigned 32-bit value. The low order bits are
|
||||
designated to hold an error code (between 1 and MAX_ERRNO). The upper bits
|
||||
are used as a counter. This is done with atomics instead of locking so that
|
||||
these functions can be called from any context.
|
||||
|
||||
Note that there is a risk of collisions if new errors are being recorded
|
||||
frequently, since we have so few bits to use as a counter.
|
||||
|
||||
To mitigate this, the bit between the error value and counter is used as
|
||||
a flag to tell whether the value has been sampled since a new value was
|
||||
recorded. That allows us to avoid bumping the counter if no one has
|
||||
sampled it since the last time an error was recorded.
|
||||
|
||||
Thus we end up with a value that looks something like this:
|
||||
|
||||
+--------------------------------------+----+------------------------+
|
||||
| 31..13 | 12 | 11..0 |
|
||||
+--------------------------------------+----+------------------------+
|
||||
| counter | SF | errno |
|
||||
+--------------------------------------+----+------------------------+
|
||||
|
||||
The general idea is for "watchers" to sample an errseq_t value and keep
|
||||
it as a running cursor. That value can later be used to tell whether
|
||||
any new errors have occurred since that sampling was done, and atomically
|
||||
record the state at the time that it was checked. This allows us to
|
||||
record errors in one place, and then have a number of "watchers" that
|
||||
can tell whether the value has changed since they last checked it.
|
||||
|
||||
A new errseq_t should always be zeroed out. An errseq_t value of all zeroes
|
||||
is the special (but common) case where there has never been an error. An all
|
||||
zero value thus serves as the "epoch" if one wishes to know whether there
|
||||
has ever been an error set since it was first initialized.
|
||||
|
||||
API usage
|
||||
=========
|
||||
|
||||
Let me tell you a story about a worker drone. Now, he's a good worker
|
||||
overall, but the company is a little...management heavy. He has to
|
||||
report to 77 supervisors today, and tomorrow the "big boss" is coming in
|
||||
from out of town and he's sure to test the poor fellow too.
|
||||
|
||||
They're all handing him work to do -- so much he can't keep track of who
|
||||
handed him what, but that's not really a big problem. The supervisors
|
||||
just want to know when he's finished all of the work they've handed him so
|
||||
far and whether he made any mistakes since they last asked.
|
||||
|
||||
He might have made the mistake on work they didn't actually hand him,
|
||||
but he can't keep track of things at that level of detail, all he can
|
||||
remember is the most recent mistake that he made.
|
||||
|
||||
Here's our worker_drone representation::
|
||||
|
||||
struct worker_drone {
|
||||
errseq_t wd_err; /* for recording errors */
|
||||
};
|
||||
|
||||
Every day, the worker_drone starts out with a blank slate::
|
||||
|
||||
struct worker_drone wd;
|
||||
|
||||
wd.wd_err = (errseq_t)0;
|
||||
|
||||
The supervisors come in and get an initial read for the day. They
|
||||
don't care about anything that happened before their watch begins::
|
||||
|
||||
struct supervisor {
|
||||
errseq_t s_wd_err; /* private "cursor" for wd_err */
|
||||
spinlock_t s_wd_err_lock; /* protects s_wd_err */
|
||||
}
|
||||
|
||||
struct supervisor su;
|
||||
|
||||
su.s_wd_err = errseq_sample(&wd.wd_err);
|
||||
spin_lock_init(&su.s_wd_err_lock);
|
||||
|
||||
Now they start handing him tasks to do. Every few minutes they ask him to
|
||||
finish up all of the work they've handed him so far. Then they ask him
|
||||
whether he made any mistakes on any of it::
|
||||
|
||||
spin_lock(&su.su_wd_err_lock);
|
||||
err = errseq_check_and_advance(&wd.wd_err, &su.s_wd_err);
|
||||
spin_unlock(&su.su_wd_err_lock);
|
||||
|
||||
Up to this point, that just keeps returning 0.
|
||||
|
||||
Now, the owners of this company are quite miserly and have given him
|
||||
substandard equipment with which to do his job. Occasionally it
|
||||
glitches and he makes a mistake. He sighs a heavy sigh, and marks it
|
||||
down::
|
||||
|
||||
errseq_set(&wd.wd_err, -EIO);
|
||||
|
||||
...and then gets back to work. The supervisors eventually poll again
|
||||
and they each get the error when they next check. Subsequent calls will
|
||||
return 0, until another error is recorded, at which point it's reported
|
||||
to each of them once.
|
||||
|
||||
Note that the supervisors can't tell how many mistakes he made, only
|
||||
whether one was made since they last checked, and the latest value
|
||||
recorded.
|
||||
|
||||
Occasionally the big boss comes in for a spot check and asks the worker
|
||||
to do a one-off job for him. He's not really watching the worker
|
||||
full-time like the supervisors, but he does need to know whether a
|
||||
mistake occurred while his job was processing.
|
||||
|
||||
He can just sample the current errseq_t in the worker, and then use that
|
||||
to tell whether an error has occurred later::
|
||||
|
||||
errseq_t since = errseq_sample(&wd.wd_err);
|
||||
/* submit some work and wait for it to complete */
|
||||
err = errseq_check(&wd.wd_err, since);
|
||||
|
||||
Since he's just going to discard "since" after that point, he doesn't
|
||||
need to advance it here. He also doesn't need any locking since it's
|
||||
not usable by anyone else.
|
||||
|
||||
Serializing errseq_t cursor updates
|
||||
===================================
|
||||
|
||||
Note that the errseq_t API does not protect the errseq_t cursor during a
|
||||
check_and_advance_operation. Only the canonical error code is handled
|
||||
atomically. In a situation where more than one task might be using the
|
||||
same errseq_t cursor at the same time, it's important to serialize
|
||||
updates to that cursor.
|
||||
|
||||
If that's not done, then it's possible for the cursor to go backward
|
||||
in which case the same error could be reported more than once.
|
||||
|
||||
Because of this, it's often advantageous to first do an errseq_check to
|
||||
see if anything has changed, and only later do an
|
||||
errseq_check_and_advance after taking the lock. e.g.::
|
||||
|
||||
if (errseq_check(&wd.wd_err, READ_ONCE(su.s_wd_err)) {
|
||||
/* su.s_wd_err is protected by s_wd_err_lock */
|
||||
spin_lock(&su.s_wd_err_lock);
|
||||
err = errseq_check_and_advance(&wd.wd_err, &su.s_wd_err);
|
||||
spin_unlock(&su.s_wd_err_lock);
|
||||
}
|
||||
|
||||
That avoids the spinlock in the common case where nothing has changed
|
||||
since the last time it was checked.
|
||||
|
||||
Functions
|
||||
=========
|
||||
|
||||
.. kernel-doc:: lib/errseq.c
|
||||
|
|
@ -14,6 +14,7 @@ Core utilities
|
|||
kernel-api
|
||||
assoc_array
|
||||
atomic_ops
|
||||
refcount-vs-atomic
|
||||
cpu_hotplug
|
||||
local_ops
|
||||
workqueue
|
||||
|
|
@ -21,6 +22,8 @@ Core utilities
|
|||
flexible-arrays
|
||||
librs
|
||||
genalloc
|
||||
errseq
|
||||
printk-formats
|
||||
|
||||
Interfaces for kernel debugging
|
||||
===============================
|
||||
|
|
|
|||
|
|
@ -139,6 +139,21 @@ Division Functions
|
|||
.. kernel-doc:: lib/gcd.c
|
||||
:export:
|
||||
|
||||
Sorting
|
||||
-------
|
||||
|
||||
.. kernel-doc:: lib/sort.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: lib/list_sort.c
|
||||
:export:
|
||||
|
||||
UUID/GUID
|
||||
---------
|
||||
|
||||
.. kernel-doc:: lib/uuid.c
|
||||
:export:
|
||||
|
||||
Memory Management in Linux
|
||||
==========================
|
||||
|
||||
|
|
|
|||
492
Documentation/core-api/printk-formats.rst
Normal file
492
Documentation/core-api/printk-formats.rst
Normal file
|
|
@ -0,0 +1,492 @@
|
|||
=========================================
|
||||
How to get printk format specifiers right
|
||||
=========================================
|
||||
|
||||
:Author: Randy Dunlap <rdunlap@infradead.org>
|
||||
:Author: Andrew Murray <amurray@mpc-data.co.uk>
|
||||
|
||||
|
||||
Integer types
|
||||
=============
|
||||
|
||||
::
|
||||
|
||||
If variable is of Type, use printk format specifier:
|
||||
------------------------------------------------------------
|
||||
int %d or %x
|
||||
unsigned int %u or %x
|
||||
long %ld or %lx
|
||||
unsigned long %lu or %lx
|
||||
long long %lld or %llx
|
||||
unsigned long long %llu or %llx
|
||||
size_t %zu or %zx
|
||||
ssize_t %zd or %zx
|
||||
s32 %d or %x
|
||||
u32 %u or %x
|
||||
s64 %lld or %llx
|
||||
u64 %llu or %llx
|
||||
|
||||
|
||||
If <type> is dependent on a config option for its size (e.g., sector_t,
|
||||
blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
|
||||
format specifier of its largest possible type and explicitly cast to it.
|
||||
|
||||
Example::
|
||||
|
||||
printk("test: sector number/total blocks: %llu/%llu\n",
|
||||
(unsigned long long)sector, (unsigned long long)blockcount);
|
||||
|
||||
Reminder: sizeof() returns type size_t.
|
||||
|
||||
The kernel's printf does not support %n. Floating point formats (%e, %f,
|
||||
%g, %a) are also not recognized, for obvious reasons. Use of any
|
||||
unsupported specifier or length qualifier results in a WARN and early
|
||||
return from vsnprintf().
|
||||
|
||||
Pointer types
|
||||
=============
|
||||
|
||||
A raw pointer value may be printed with %p which will hash the address
|
||||
before printing. The kernel also supports extended specifiers for printing
|
||||
pointers of different types.
|
||||
|
||||
Plain Pointers
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
%p abcdef12 or 00000000abcdef12
|
||||
|
||||
Pointers printed without a specifier extension (i.e unadorned %p) are
|
||||
hashed to prevent leaking information about the kernel memory layout. This
|
||||
has the added benefit of providing a unique identifier. On 64-bit machines
|
||||
the first 32 bits are zeroed. If you *really* want the address see %px
|
||||
below.
|
||||
|
||||
Symbols/Function Pointers
|
||||
-------------------------
|
||||
|
||||
::
|
||||
|
||||
%pF versatile_init+0x0/0x110
|
||||
%pf versatile_init
|
||||
%pS versatile_init+0x0/0x110
|
||||
%pSR versatile_init+0x9/0x110
|
||||
(with __builtin_extract_return_addr() translation)
|
||||
%ps versatile_init
|
||||
%pB prev_fn_of_versatile_init+0x88/0x88
|
||||
|
||||
|
||||
The ``F`` and ``f`` specifiers are for printing function pointers,
|
||||
for example, f->func, &gettimeofday. They have the same result as
|
||||
``S`` and ``s`` specifiers. But they do an extra conversion on
|
||||
ia64, ppc64 and parisc64 architectures where the function pointers
|
||||
are actually function descriptors.
|
||||
|
||||
The ``S`` and ``s`` specifiers can be used for printing symbols
|
||||
from direct addresses, for example, __builtin_return_address(0),
|
||||
(void *)regs->ip. They result in the symbol name with (S) or
|
||||
without (s) offsets. If KALLSYMS are disabled then the symbol
|
||||
address is printed instead.
|
||||
|
||||
The ``B`` specifier results in the symbol name with offsets and should be
|
||||
used when printing stack backtraces. The specifier takes into
|
||||
consideration the effect of compiler optimisations which may occur
|
||||
when tail-calls are used and marked with the noreturn GCC attribute.
|
||||
|
||||
Examples::
|
||||
|
||||
printk("Going to call: %pF\n", gettimeofday);
|
||||
printk("Going to call: %pF\n", p->func);
|
||||
printk("%s: called from %pS\n", __func__, (void *)_RET_IP_);
|
||||
printk("%s: called from %pS\n", __func__,
|
||||
(void *)__builtin_return_address(0));
|
||||
printk("Faulted at %pS\n", (void *)regs->ip);
|
||||
printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
|
||||
|
||||
Kernel Pointers
|
||||
---------------
|
||||
|
||||
::
|
||||
|
||||
%pK 01234567 or 0123456789abcdef
|
||||
|
||||
For printing kernel pointers which should be hidden from unprivileged
|
||||
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
|
||||
Documentation/sysctl/kernel.txt for more details.
|
||||
|
||||
Unmodified Addresses
|
||||
--------------------
|
||||
|
||||
::
|
||||
|
||||
%px 01234567 or 0123456789abcdef
|
||||
|
||||
For printing pointers when you *really* want to print the address. Please
|
||||
consider whether or not you are leaking sensitive information about the
|
||||
kernel memory layout before printing pointers with %px. %px is functionally
|
||||
equivalent to %lx (or %lu). %px is preferred because it is more uniquely
|
||||
grep'able. If in the future we need to modify the way the kernel handles
|
||||
printing pointers we will be better equipped to find the call sites.
|
||||
|
||||
Struct Resources
|
||||
----------------
|
||||
|
||||
::
|
||||
|
||||
%pr [mem 0x60000000-0x6fffffff flags 0x2200] or
|
||||
[mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
|
||||
%pR [mem 0x60000000-0x6fffffff pref] or
|
||||
[mem 0x0000000060000000-0x000000006fffffff pref]
|
||||
|
||||
For printing struct resources. The ``R`` and ``r`` specifiers result in a
|
||||
printed resource with (R) or without (r) a decoded flags member.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Physical address types phys_addr_t
|
||||
----------------------------------
|
||||
|
||||
::
|
||||
|
||||
%pa[p] 0x01234567 or 0x0123456789abcdef
|
||||
|
||||
For printing a phys_addr_t type (and its derivatives, such as
|
||||
resource_size_t) which can vary based on build options, regardless of the
|
||||
width of the CPU data path.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
DMA address types dma_addr_t
|
||||
----------------------------
|
||||
|
||||
::
|
||||
|
||||
%pad 0x01234567 or 0x0123456789abcdef
|
||||
|
||||
For printing a dma_addr_t type which can vary based on build options,
|
||||
regardless of the width of the CPU data path.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Raw buffer as an escaped string
|
||||
-------------------------------
|
||||
|
||||
::
|
||||
|
||||
%*pE[achnops]
|
||||
|
||||
For printing raw buffer as an escaped string. For the following buffer::
|
||||
|
||||
1b 62 20 5c 43 07 22 90 0d 5d
|
||||
|
||||
A few examples show how the conversion would be done (excluding surrounding
|
||||
quotes)::
|
||||
|
||||
%*pE "\eb \C\a"\220\r]"
|
||||
%*pEhp "\x1bb \C\x07"\x90\x0d]"
|
||||
%*pEa "\e\142\040\\\103\a\042\220\r\135"
|
||||
|
||||
The conversion rules are applied according to an optional combination
|
||||
of flags (see :c:func:`string_escape_mem` kernel documentation for the
|
||||
details):
|
||||
|
||||
- a - ESCAPE_ANY
|
||||
- c - ESCAPE_SPECIAL
|
||||
- h - ESCAPE_HEX
|
||||
- n - ESCAPE_NULL
|
||||
- o - ESCAPE_OCTAL
|
||||
- p - ESCAPE_NP
|
||||
- s - ESCAPE_SPACE
|
||||
|
||||
By default ESCAPE_ANY_NP is used.
|
||||
|
||||
ESCAPE_ANY_NP is the sane choice for many cases, in particularly for
|
||||
printing SSIDs.
|
||||
|
||||
If field width is omitted then 1 byte only will be escaped.
|
||||
|
||||
Raw buffer as a hex string
|
||||
--------------------------
|
||||
|
||||
::
|
||||
|
||||
%*ph 00 01 02 ... 3f
|
||||
%*phC 00:01:02: ... :3f
|
||||
%*phD 00-01-02- ... -3f
|
||||
%*phN 000102 ... 3f
|
||||
|
||||
For printing small buffers (up to 64 bytes long) as a hex string with a
|
||||
certain separator. For larger buffers consider using
|
||||
:c:func:`print_hex_dump`.
|
||||
|
||||
MAC/FDDI addresses
|
||||
------------------
|
||||
|
||||
::
|
||||
|
||||
%pM 00:01:02:03:04:05
|
||||
%pMR 05:04:03:02:01:00
|
||||
%pMF 00-01-02-03-04-05
|
||||
%pm 000102030405
|
||||
%pmR 050403020100
|
||||
|
||||
For printing 6-byte MAC/FDDI addresses in hex notation. The ``M`` and ``m``
|
||||
specifiers result in a printed address with (M) or without (m) byte
|
||||
separators. The default byte separator is the colon (:).
|
||||
|
||||
Where FDDI addresses are concerned the ``F`` specifier can be used after
|
||||
the ``M`` specifier to use dash (-) separators instead of the default
|
||||
separator.
|
||||
|
||||
For Bluetooth addresses the ``R`` specifier shall be used after the ``M``
|
||||
specifier to use reversed byte order suitable for visual interpretation
|
||||
of Bluetooth addresses which are in the little endian order.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
IPv4 addresses
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
%pI4 1.2.3.4
|
||||
%pi4 001.002.003.004
|
||||
%p[Ii]4[hnbl]
|
||||
|
||||
For printing IPv4 dot-separated decimal addresses. The ``I4`` and ``i4``
|
||||
specifiers result in a printed address with (i4) or without (I4) leading
|
||||
zeros.
|
||||
|
||||
The additional ``h``, ``n``, ``b``, and ``l`` specifiers are used to specify
|
||||
host, network, big or little endian order addresses respectively. Where
|
||||
no specifier is provided the default network/big endian order is used.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
IPv6 addresses
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
%pI6 0001:0002:0003:0004:0005:0006:0007:0008
|
||||
%pi6 00010002000300040005000600070008
|
||||
%pI6c 1:2:3:4:5:6:7:8
|
||||
|
||||
For printing IPv6 network-order 16-bit hex addresses. The ``I6`` and ``i6``
|
||||
specifiers result in a printed address with (I6) or without (i6)
|
||||
colon-separators. Leading zeros are always used.
|
||||
|
||||
The additional ``c`` specifier can be used with the ``I`` specifier to
|
||||
print a compressed IPv6 address as described by
|
||||
http://tools.ietf.org/html/rfc5952
|
||||
|
||||
Passed by reference.
|
||||
|
||||
IPv4/IPv6 addresses (generic, with port, flowinfo, scope)
|
||||
---------------------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
%pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008
|
||||
%piS 001.002.003.004 or 00010002000300040005000600070008
|
||||
%pISc 1.2.3.4 or 1:2:3:4:5:6:7:8
|
||||
%pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
|
||||
%p[Ii]S[pfschnbl]
|
||||
|
||||
For printing an IP address without the need to distinguish whether it's of
|
||||
type AF_INET or AF_INET6. A pointer to a valid struct sockaddr,
|
||||
specified through ``IS`` or ``iS``, can be passed to this format specifier.
|
||||
|
||||
The additional ``p``, ``f``, and ``s`` specifiers are used to specify port
|
||||
(IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ``:`` prefix,
|
||||
flowinfo a ``/`` and scope a ``%``, each followed by the actual value.
|
||||
|
||||
In case of an IPv6 address the compressed IPv6 address as described by
|
||||
http://tools.ietf.org/html/rfc5952 is being used if the additional
|
||||
specifier ``c`` is given. The IPv6 address is surrounded by ``[``, ``]`` in
|
||||
case of additional specifiers ``p``, ``f`` or ``s`` as suggested by
|
||||
https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
|
||||
|
||||
In case of IPv4 addresses, the additional ``h``, ``n``, ``b``, and ``l``
|
||||
specifiers can be used as well and are ignored in case of an IPv6
|
||||
address.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Further examples::
|
||||
|
||||
%pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789
|
||||
%pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890
|
||||
%pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
|
||||
|
||||
UUID/GUID addresses
|
||||
-------------------
|
||||
|
||||
::
|
||||
|
||||
%pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
|
||||
%pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
|
||||
%pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
|
||||
%pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
|
||||
|
||||
For printing 16-byte UUID/GUIDs addresses. The additional ``l``, ``L``,
|
||||
``b`` and ``B`` specifiers are used to specify a little endian order in
|
||||
lower (l) or upper case (L) hex notation - and big endian order in lower (b)
|
||||
or upper case (B) hex notation.
|
||||
|
||||
Where no additional specifiers are used the default big endian
|
||||
order with lower case hex notation will be printed.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
dentry names
|
||||
------------
|
||||
|
||||
::
|
||||
|
||||
%pd{,2,3,4}
|
||||
%pD{,2,3,4}
|
||||
|
||||
For printing dentry name; if we race with :c:func:`d_move`, the name might
|
||||
be a mix of old and new ones, but it won't oops. %pd dentry is a safer
|
||||
equivalent of %s dentry->d_name.name we used to use, %pd<n> prints ``n``
|
||||
last components. %pD does the same thing for struct file.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
block_device names
|
||||
------------------
|
||||
|
||||
::
|
||||
|
||||
%pg sda, sda1 or loop0p1
|
||||
|
||||
For printing name of block_device pointers.
|
||||
|
||||
struct va_format
|
||||
----------------
|
||||
|
||||
::
|
||||
|
||||
%pV
|
||||
|
||||
For printing struct va_format structures. These contain a format string
|
||||
and va_list as follows::
|
||||
|
||||
struct va_format {
|
||||
const char *fmt;
|
||||
va_list *va;
|
||||
};
|
||||
|
||||
Implements a "recursive vsnprintf".
|
||||
|
||||
Do not use this feature without some mechanism to verify the
|
||||
correctness of the format string and va_list arguments.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
kobjects
|
||||
--------
|
||||
|
||||
::
|
||||
|
||||
%pOF[fnpPcCF]
|
||||
|
||||
|
||||
For printing kobject based structs (device nodes). Default behaviour is
|
||||
equivalent to %pOFf.
|
||||
|
||||
- f - device node full_name
|
||||
- n - device node name
|
||||
- p - device node phandle
|
||||
- P - device node path spec (name + @unit)
|
||||
- F - device node flags
|
||||
- c - major compatible string
|
||||
- C - full compatible string
|
||||
|
||||
The separator when using multiple arguments is ':'
|
||||
|
||||
Examples::
|
||||
|
||||
%pOF /foo/bar@0 - Node full name
|
||||
%pOFf /foo/bar@0 - Same as above
|
||||
%pOFfp /foo/bar@0:10 - Node full name + phandle
|
||||
%pOFfcF /foo/bar@0:foo,device:--P- - Node full name +
|
||||
major compatible string +
|
||||
node flags
|
||||
D - dynamic
|
||||
d - detached
|
||||
P - Populated
|
||||
B - Populated bus
|
||||
|
||||
Passed by reference.
|
||||
|
||||
struct clk
|
||||
----------
|
||||
|
||||
::
|
||||
|
||||
%pC pll1
|
||||
%pCn pll1
|
||||
%pCr 1560000000
|
||||
|
||||
For printing struct clk structures. %pC and %pCn print the name
|
||||
(Common Clock Framework) or address (legacy clock framework) of the
|
||||
structure; %pCr prints the current clock rate.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
bitmap and its derivatives such as cpumask and nodemask
|
||||
-------------------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
%*pb 0779
|
||||
%*pbl 0,3-6,8-10
|
||||
|
||||
For printing bitmap and its derivatives such as cpumask and nodemask,
|
||||
%*pb outputs the bitmap with field width as the number of bits and %*pbl
|
||||
output the bitmap as range list with field width as the number of bits.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Flags bitfields such as page flags, gfp_flags
|
||||
---------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
%pGp referenced|uptodate|lru|active|private
|
||||
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
|
||||
%pGv read|exec|mayread|maywrite|mayexec|denywrite
|
||||
|
||||
For printing flags bitfields as a collection of symbolic constants that
|
||||
would construct the value. The type of flags is given by the third
|
||||
character. Currently supported are [p]age flags, [v]ma_flags (both
|
||||
expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag
|
||||
names and print order depends on the particular type.
|
||||
|
||||
Note that this format should not be used directly in the
|
||||
:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags()
|
||||
functions from <trace/events/mmflags.h>.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Network device features
|
||||
-----------------------
|
||||
|
||||
::
|
||||
|
||||
%pNF 0x000000000000c000
|
||||
|
||||
For printing netdev_features_t.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
Thanks
|
||||
======
|
||||
|
||||
If you add other %p extensions, please extend <lib/test_printf.c> with
|
||||
one or more test cases, if at all feasible.
|
||||
|
||||
Thank you for your cooperation and attention.
|
||||
150
Documentation/core-api/refcount-vs-atomic.rst
Normal file
150
Documentation/core-api/refcount-vs-atomic.rst
Normal file
|
|
@ -0,0 +1,150 @@
|
|||
===================================
|
||||
refcount_t API compared to atomic_t
|
||||
===================================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The goal of refcount_t API is to provide a minimal API for implementing
|
||||
an object's reference counters. While a generic architecture-independent
|
||||
implementation from lib/refcount.c uses atomic operations underneath,
|
||||
there are a number of differences between some of the ``refcount_*()`` and
|
||||
``atomic_*()`` functions with regards to the memory ordering guarantees.
|
||||
This document outlines the differences and provides respective examples
|
||||
in order to help maintainers validate their code against the change in
|
||||
these memory ordering guarantees.
|
||||
|
||||
The terms used through this document try to follow the formal LKMM defined in
|
||||
github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
|
||||
|
||||
memory-barriers.txt and atomic_t.txt provide more background to the
|
||||
memory ordering in general and for atomic operations specifically.
|
||||
|
||||
Relevant types of memory ordering
|
||||
=================================
|
||||
|
||||
.. note:: The following section only covers some of the memory
|
||||
ordering types that are relevant for the atomics and reference
|
||||
counters and used through this document. For a much broader picture
|
||||
please consult memory-barriers.txt document.
|
||||
|
||||
In the absence of any memory ordering guarantees (i.e. fully unordered)
|
||||
atomics & refcounters only provide atomicity and
|
||||
program order (po) relation (on the same CPU). It guarantees that
|
||||
each ``atomic_*()`` and ``refcount_*()`` operation is atomic and instructions
|
||||
are executed in program order on a single CPU.
|
||||
This is implemented using :c:func:`READ_ONCE`/:c:func:`WRITE_ONCE` and
|
||||
compare-and-swap primitives.
|
||||
|
||||
A strong (full) memory ordering guarantees that all prior loads and
|
||||
stores (all po-earlier instructions) on the same CPU are completed
|
||||
before any po-later instruction is executed on the same CPU.
|
||||
It also guarantees that all po-earlier stores on the same CPU
|
||||
and all propagated stores from other CPUs must propagate to all
|
||||
other CPUs before any po-later instruction is executed on the original
|
||||
CPU (A-cumulative property). This is implemented using :c:func:`smp_mb`.
|
||||
|
||||
A RELEASE memory ordering guarantees that all prior loads and
|
||||
stores (all po-earlier instructions) on the same CPU are completed
|
||||
before the operation. It also guarantees that all po-earlier
|
||||
stores on the same CPU and all propagated stores from other CPUs
|
||||
must propagate to all other CPUs before the release operation
|
||||
(A-cumulative property). This is implemented using
|
||||
:c:func:`smp_store_release`.
|
||||
|
||||
A control dependency (on success) for refcounters guarantees that
|
||||
if a reference for an object was successfully obtained (reference
|
||||
counter increment or addition happened, function returned true),
|
||||
then further stores are ordered against this operation.
|
||||
Control dependency on stores are not implemented using any explicit
|
||||
barriers, but rely on CPU not to speculate on stores. This is only
|
||||
a single CPU relation and provides no guarantees for other CPUs.
|
||||
|
||||
|
||||
Comparison of functions
|
||||
=======================
|
||||
|
||||
case 1) - non-"Read/Modify/Write" (RMW) ops
|
||||
-------------------------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_set` --> :c:func:`refcount_set`
|
||||
* :c:func:`atomic_read` --> :c:func:`refcount_read`
|
||||
|
||||
Memory ordering guarantee changes:
|
||||
|
||||
* none (both fully unordered)
|
||||
|
||||
|
||||
case 2) - increment-based ops that return no value
|
||||
--------------------------------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_inc` --> :c:func:`refcount_inc`
|
||||
* :c:func:`atomic_add` --> :c:func:`refcount_add`
|
||||
|
||||
Memory ordering guarantee changes:
|
||||
|
||||
* none (both fully unordered)
|
||||
|
||||
case 3) - decrement-based RMW ops that return no value
|
||||
------------------------------------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_dec` --> :c:func:`refcount_dec`
|
||||
|
||||
Memory ordering guarantee changes:
|
||||
|
||||
* fully unordered --> RELEASE ordering
|
||||
|
||||
|
||||
case 4) - increment-based RMW ops that return a value
|
||||
-----------------------------------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_inc_not_zero` --> :c:func:`refcount_inc_not_zero`
|
||||
* no atomic counterpart --> :c:func:`refcount_add_not_zero`
|
||||
|
||||
Memory ordering guarantees changes:
|
||||
|
||||
* fully ordered --> control dependency on success for stores
|
||||
|
||||
.. note:: We really assume here that necessary ordering is provided as a
|
||||
result of obtaining pointer to the object!
|
||||
|
||||
|
||||
case 5) - decrement-based RMW ops that return a value
|
||||
-----------------------------------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_dec_and_test` --> :c:func:`refcount_dec_and_test`
|
||||
* :c:func:`atomic_sub_and_test` --> :c:func:`refcount_sub_and_test`
|
||||
* no atomic counterpart --> :c:func:`refcount_dec_if_one`
|
||||
* ``atomic_add_unless(&var, -1, 1)`` --> ``refcount_dec_not_one(&var)``
|
||||
|
||||
Memory ordering guarantees changes:
|
||||
|
||||
* fully ordered --> RELEASE ordering + control dependency
|
||||
|
||||
.. note:: :c:func:`atomic_add_unless` only provides full order on success.
|
||||
|
||||
|
||||
case 6) - lock-based RMW
|
||||
------------------------
|
||||
|
||||
Function changes:
|
||||
|
||||
* :c:func:`atomic_dec_and_lock` --> :c:func:`refcount_dec_and_lock`
|
||||
* :c:func:`atomic_dec_and_mutex_lock` --> :c:func:`refcount_dec_and_mutex_lock`
|
||||
|
||||
Memory ordering guarantees changes:
|
||||
|
||||
* fully ordered --> RELEASE ordering + control dependency + hold
|
||||
:c:func:`spin_lock` on success
|
||||
|
|
@ -112,16 +112,17 @@ Example kernel-doc function comment::
|
|||
|
||||
/**
|
||||
* foobar() - Brief description of foobar.
|
||||
* @arg: Description of argument of foobar.
|
||||
* @argument1: Description of parameter argument1 of foobar.
|
||||
* @argument2: Description of parameter argument2 of foobar.
|
||||
*
|
||||
* Longer description of foobar.
|
||||
*
|
||||
* Return: Description of return value of foobar.
|
||||
*/
|
||||
int foobar(int arg)
|
||||
int foobar(int argument1, char *argument2)
|
||||
|
||||
The format is similar for documentation for structures, enums, paragraphs,
|
||||
etc. See the sections below for details.
|
||||
etc. See the sections below for specific details of each type.
|
||||
|
||||
The kernel-doc structure is extracted from the comments, and proper `Sphinx C
|
||||
Domain`_ function and type descriptions with anchors are generated for them. The
|
||||
|
|
@ -130,6 +131,226 @@ cross-references. See below for details.
|
|||
|
||||
.. _Sphinx C Domain: http://www.sphinx-doc.org/en/stable/domains.html
|
||||
|
||||
|
||||
Parameters and member arguments
|
||||
-------------------------------
|
||||
|
||||
The kernel-doc function comments describe each parameter to the function and
|
||||
function typedefs or each member of struct/union, in order, with the
|
||||
``@argument:`` descriptions. For each non-private member argument, one
|
||||
``@argument`` definition is needed.
|
||||
|
||||
The ``@argument:`` descriptions begin on the very next line following
|
||||
the opening brief function description line, with no intervening blank
|
||||
comment lines.
|
||||
|
||||
The ``@argument:`` descriptions may span multiple lines.
|
||||
|
||||
.. note::
|
||||
|
||||
If the ``@argument`` description has multiple lines, the continuation
|
||||
of the description should be starting exactly at the same column as
|
||||
the previous line, e. g.::
|
||||
|
||||
* @argument: some long description
|
||||
* that continues on next lines
|
||||
|
||||
or::
|
||||
|
||||
* @argument:
|
||||
* some long description
|
||||
* that continues on next lines
|
||||
|
||||
If a function or typedef parameter argument is ``...`` (e. g. a variable
|
||||
number of arguments), its description should be listed in kernel-doc
|
||||
notation as::
|
||||
|
||||
* @...: description
|
||||
|
||||
Private members
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Inside a struct or union description, you can use the ``private:`` and
|
||||
``public:`` comment tags. Structure fields that are inside a ``private:``
|
||||
area are not listed in the generated output documentation.
|
||||
|
||||
The ``private:`` and ``public:`` tags must begin immediately following a
|
||||
``/*`` comment marker. They may optionally include comments between the
|
||||
``:`` and the ending ``*/`` marker.
|
||||
|
||||
Example::
|
||||
|
||||
/**
|
||||
* struct my_struct - short description
|
||||
* @a: first member
|
||||
* @b: second member
|
||||
* @d: fourth member
|
||||
*
|
||||
* Longer description
|
||||
*/
|
||||
struct my_struct {
|
||||
int a;
|
||||
int b;
|
||||
/* private: internal use only */
|
||||
int c;
|
||||
/* public: the next one is public */
|
||||
int d;
|
||||
};
|
||||
|
||||
Function documentation
|
||||
----------------------
|
||||
|
||||
The general format of a function and function-like macro kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* function_name() - Brief description of function.
|
||||
* @arg1: Describe the first argument.
|
||||
* @arg2: Describe the second argument.
|
||||
* One can provide multiple line descriptions
|
||||
* for arguments.
|
||||
*
|
||||
* A longer description, with more discussion of the function function_name()
|
||||
* that might be useful to those using or modifying it. Begins with an
|
||||
* empty comment line, and may include additional embedded empty
|
||||
* comment lines.
|
||||
*
|
||||
* The longer description may have multiple paragraphs.
|
||||
*
|
||||
* Return: Describe the return value of foobar.
|
||||
*
|
||||
* The return value description can also have multiple paragraphs, and should
|
||||
* be placed at the end of the comment block.
|
||||
*/
|
||||
|
||||
The brief description following the function name may span multiple lines, and
|
||||
ends with an argument description, a blank comment line, or the end of the
|
||||
comment block.
|
||||
|
||||
Return values
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The return value, if any, should be described in a dedicated section
|
||||
named ``Return``.
|
||||
|
||||
.. note::
|
||||
|
||||
#) The multi-line descriptive text you provide does *not* recognize
|
||||
line breaks, so if you try to format some text nicely, as in::
|
||||
|
||||
* Return:
|
||||
* 0 - OK
|
||||
* -EINVAL - invalid argument
|
||||
* -ENOMEM - out of memory
|
||||
|
||||
this will all run together and produce::
|
||||
|
||||
Return: 0 - OK -EINVAL - invalid argument -ENOMEM - out of memory
|
||||
|
||||
So, in order to produce the desired line breaks, you need to use a
|
||||
ReST list, e. g.::
|
||||
|
||||
* Return:
|
||||
* * 0 - OK to runtime suspend the device
|
||||
* * -EBUSY - Device should not be runtime suspended
|
||||
|
||||
#) If the descriptive text you provide has lines that begin with
|
||||
some phrase followed by a colon, each of those phrases will be taken
|
||||
as a new section heading, with probably won't produce the desired
|
||||
effect.
|
||||
|
||||
Structure, union, and enumeration documentation
|
||||
-----------------------------------------------
|
||||
|
||||
The general format of a struct, union, and enum kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* struct struct_name - Brief description.
|
||||
* @argument: Description of member member_name.
|
||||
*
|
||||
* Description of the structure.
|
||||
*/
|
||||
|
||||
On the above, ``struct`` is used to mean structs. You can also use ``union``
|
||||
and ``enum`` to describe unions and enums. ``argument`` is used
|
||||
to mean struct and union member names as well as enumerations in an enum.
|
||||
|
||||
The brief description following the structure name may span multiple lines, and
|
||||
ends with a member description, a blank comment line, or the end of the
|
||||
comment block.
|
||||
|
||||
The kernel-doc data structure comments describe each member of the structure,
|
||||
in order, with the member descriptions.
|
||||
|
||||
Nested structs/unions
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is possible to document nested structs unions, like::
|
||||
|
||||
/**
|
||||
* struct nested_foobar - a struct with nested unions and structs
|
||||
* @arg1: - first argument of anonymous union/anonymous struct
|
||||
* @arg2: - second argument of anonymous union/anonymous struct
|
||||
* @arg3: - third argument of anonymous union/anonymous struct
|
||||
* @arg4: - fourth argument of anonymous union/anonymous struct
|
||||
* @bar.st1.arg1 - first argument of struct st1 on union bar
|
||||
* @bar.st1.arg2 - second argument of struct st1 on union bar
|
||||
* @bar.st2.arg1 - first argument of struct st2 on union bar
|
||||
* @bar.st2.arg2 - second argument of struct st2 on union bar
|
||||
struct nested_foobar {
|
||||
/* Anonymous union/struct*/
|
||||
union {
|
||||
struct {
|
||||
int arg1;
|
||||
int arg2;
|
||||
}
|
||||
struct {
|
||||
void *arg3;
|
||||
int arg4;
|
||||
}
|
||||
}
|
||||
union {
|
||||
struct {
|
||||
int arg1;
|
||||
int arg2;
|
||||
} st1;
|
||||
struct {
|
||||
void *arg1;
|
||||
int arg2;
|
||||
} st2;
|
||||
} bar;
|
||||
};
|
||||
|
||||
.. note::
|
||||
|
||||
#) When documenting nested structs or unions, if the struct/union ``foo``
|
||||
is named, the argument ``bar`` inside it should be documented as
|
||||
``@foo.bar:``
|
||||
#) When the nested struct/union is anonymous, the argument ``bar`` on it
|
||||
should be documented as ``@bar:``
|
||||
|
||||
Typedef documentation
|
||||
---------------------
|
||||
|
||||
The general format of a typedef kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* typedef type_name - Brief description.
|
||||
*
|
||||
* Description of the type.
|
||||
*/
|
||||
|
||||
Typedefs with function prototypes can also be documented::
|
||||
|
||||
/**
|
||||
* typedef type_name - Brief description.
|
||||
* @arg1: description of arg1
|
||||
* @arg2: description of arg2
|
||||
*
|
||||
* Description of the type.
|
||||
*/
|
||||
typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2);
|
||||
|
||||
|
||||
Highlights and cross-references
|
||||
-------------------------------
|
||||
|
||||
|
|
@ -201,70 +422,7 @@ cross-references.
|
|||
|
||||
For further details, please refer to the `Sphinx C Domain`_ documentation.
|
||||
|
||||
Function documentation
|
||||
----------------------
|
||||
|
||||
The general format of a function and function-like macro kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* function_name() - Brief description of function.
|
||||
* @arg1: Describe the first argument.
|
||||
* @arg2: Describe the second argument.
|
||||
* One can provide multiple line descriptions
|
||||
* for arguments.
|
||||
*
|
||||
* A longer description, with more discussion of the function function_name()
|
||||
* that might be useful to those using or modifying it. Begins with an
|
||||
* empty comment line, and may include additional embedded empty
|
||||
* comment lines.
|
||||
*
|
||||
* The longer description may have multiple paragraphs.
|
||||
*
|
||||
* Return: Describe the return value of foobar.
|
||||
*
|
||||
* The return value description can also have multiple paragraphs, and should
|
||||
* be placed at the end of the comment block.
|
||||
*/
|
||||
|
||||
The brief description following the function name may span multiple lines, and
|
||||
ends with an ``@argument:`` description, a blank comment line, or the end of the
|
||||
comment block.
|
||||
|
||||
The kernel-doc function comments describe each parameter to the function, in
|
||||
order, with the ``@argument:`` descriptions. The ``@argument:`` descriptions
|
||||
must begin on the very next line following the opening brief function
|
||||
description line, with no intervening blank comment lines. The ``@argument:``
|
||||
descriptions may span multiple lines. The continuation lines may contain
|
||||
indentation. If a function parameter is ``...`` (varargs), it should be listed
|
||||
in kernel-doc notation as: ``@...:``.
|
||||
|
||||
The return value, if any, should be described in a dedicated section at the end
|
||||
of the comment starting with "Return:".
|
||||
|
||||
Structure, union, and enumeration documentation
|
||||
-----------------------------------------------
|
||||
|
||||
The general format of a struct, union, and enum kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* struct struct_name - Brief description.
|
||||
* @member_name: Description of member member_name.
|
||||
*
|
||||
* Description of the structure.
|
||||
*/
|
||||
|
||||
Below, "struct" is used to mean structs, unions and enums, and "member" is used
|
||||
to mean struct and union members as well as enumerations in an enum.
|
||||
|
||||
The brief description following the structure name may span multiple lines, and
|
||||
ends with a ``@member:`` description, a blank comment line, or the end of the
|
||||
comment block.
|
||||
|
||||
The kernel-doc data structure comments describe each member of the structure, in
|
||||
order, with the ``@member:`` descriptions. The ``@member:`` descriptions must
|
||||
begin on the very next line following the opening brief function description
|
||||
line, with no intervening blank comment lines. The ``@member:`` descriptions may
|
||||
span multiple lines. The continuation lines may contain indentation.
|
||||
|
||||
In-line member documentation comments
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -294,42 +452,6 @@ on a line of their own, like all other kernel-doc comments::
|
|||
int foobar;
|
||||
}
|
||||
|
||||
Private members
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Inside a struct description, you can use the "private:" and "public:" comment
|
||||
tags. Structure fields that are inside a "private:" area are not listed in the
|
||||
generated output documentation. The "private:" and "public:" tags must begin
|
||||
immediately following a ``/*`` comment marker. They may optionally include
|
||||
comments between the ``:`` and the ending ``*/`` marker.
|
||||
|
||||
Example::
|
||||
|
||||
/**
|
||||
* struct my_struct - short description
|
||||
* @a: first member
|
||||
* @b: second member
|
||||
*
|
||||
* Longer description
|
||||
*/
|
||||
struct my_struct {
|
||||
int a;
|
||||
int b;
|
||||
/* private: internal use only */
|
||||
int c;
|
||||
};
|
||||
|
||||
|
||||
Typedef documentation
|
||||
---------------------
|
||||
|
||||
The general format of a typedef kernel-doc comment is::
|
||||
|
||||
/**
|
||||
* typedef type_name - Brief description.
|
||||
*
|
||||
* Description of the type.
|
||||
*/
|
||||
|
||||
Overview documentation comments
|
||||
-------------------------------
|
||||
|
|
@ -376,3 +498,37 @@ file.
|
|||
|
||||
Data structures visible in kernel include files should also be documented using
|
||||
kernel-doc formatted comments.
|
||||
|
||||
How to use kernel-doc to generate man pages
|
||||
-------------------------------------------
|
||||
|
||||
If you just want to use kernel-doc to generate man pages you can do this
|
||||
from the Kernel git tree::
|
||||
|
||||
$ scripts/kernel-doc -man $(git grep -l '/\*\*' |grep -v Documentation/) | ./split-man.pl /tmp/man
|
||||
|
||||
Using the small ``split-man.pl`` script below::
|
||||
|
||||
|
||||
#!/usr/bin/perl
|
||||
|
||||
if ($#ARGV < 0) {
|
||||
die "where do I put the results?\n";
|
||||
}
|
||||
|
||||
mkdir $ARGV[0],0777;
|
||||
$state = 0;
|
||||
while (<STDIN>) {
|
||||
if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
|
||||
if ($state == 1) { close OUT }
|
||||
$state = 1;
|
||||
$fn = "$ARGV[0]/$1.9";
|
||||
print STDERR "Creating $fn\n";
|
||||
open OUT, ">$fn" or die "can't open $fn: $!\n";
|
||||
print OUT $_;
|
||||
} elsif ($state != 0) {
|
||||
print OUT $_;
|
||||
}
|
||||
}
|
||||
|
||||
close OUT;
|
||||
|
|
|
|||
|
|
@ -13,12 +13,6 @@ Driver device table
|
|||
.. kernel-doc:: include/linux/mod_devicetable.h
|
||||
:internal:
|
||||
|
||||
Atomic and pointer manipulation
|
||||
-------------------------------
|
||||
|
||||
.. kernel-doc:: arch/x86/include/asm/atomic.h
|
||||
:internal:
|
||||
|
||||
Delaying, scheduling, and timer routines
|
||||
----------------------------------------
|
||||
|
||||
|
|
@ -85,6 +79,21 @@ Internal Functions
|
|||
.. kernel-doc:: kernel/kthread.c
|
||||
:export:
|
||||
|
||||
Reference counting
|
||||
------------------
|
||||
|
||||
.. kernel-doc:: include/linux/refcount.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: lib/refcount.c
|
||||
:export:
|
||||
|
||||
Atomics
|
||||
-------
|
||||
|
||||
.. kernel-doc:: arch/x86/include/asm/atomic.h
|
||||
:internal:
|
||||
|
||||
Kernel objects manipulation
|
||||
---------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -98,3 +98,55 @@ you to check the sanity of the setup.
|
|||
cat /dev/ttyUSB0
|
||||
done
|
||||
===== end of bash scripts ===============
|
||||
|
||||
Serial TTY
|
||||
==========
|
||||
|
||||
The DbC support has been added to the xHCI driver. You can get a
|
||||
debug device provided by the DbC at runtime.
|
||||
|
||||
In order to use this, you need to make sure your kernel has been
|
||||
configured to support USB_XHCI_DBGCAP. A sysfs attribute under
|
||||
the xHCI device node is used to enable or disable DbC. By default,
|
||||
DbC is disabled::
|
||||
|
||||
root@target:/sys/bus/pci/devices/0000:00:14.0# cat dbc
|
||||
disabled
|
||||
|
||||
Enable DbC with the following command::
|
||||
|
||||
root@target:/sys/bus/pci/devices/0000:00:14.0# echo enable > dbc
|
||||
|
||||
You can check the DbC state at anytime::
|
||||
|
||||
root@target:/sys/bus/pci/devices/0000:00:14.0# cat dbc
|
||||
enabled
|
||||
|
||||
Connect the debug target to the debug host with a USB 3.0 super-
|
||||
speed A-to-A debugging cable. You can see /dev/ttyDBC0 created
|
||||
on the debug target. You will see below kernel message lines::
|
||||
|
||||
root@target: tail -f /var/log/kern.log
|
||||
[ 182.730103] xhci_hcd 0000:00:14.0: DbC connected
|
||||
[ 191.169420] xhci_hcd 0000:00:14.0: DbC configured
|
||||
[ 191.169597] xhci_hcd 0000:00:14.0: DbC now attached to /dev/ttyDBC0
|
||||
|
||||
Accordingly, the DbC state has been brought up to::
|
||||
|
||||
root@target:/sys/bus/pci/devices/0000:00:14.0# cat dbc
|
||||
configured
|
||||
|
||||
On the debug host, you will see the debug device has been enumerated.
|
||||
You will see below kernel message lines::
|
||||
|
||||
root@host: tail -f /var/log/kern.log
|
||||
[ 79.454780] usb 2-2.1: new SuperSpeed USB device number 3 using xhci_hcd
|
||||
[ 79.475003] usb 2-2.1: LPM exit latency is zeroed, disabling LPM.
|
||||
[ 79.475389] usb 2-2.1: New USB device found, idVendor=1d6b, idProduct=0010
|
||||
[ 79.475390] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
|
||||
[ 79.475391] usb 2-2.1: Product: Linux USB Debug Target
|
||||
[ 79.475392] usb 2-2.1: Manufacturer: Linux Foundation
|
||||
[ 79.475393] usb 2-2.1: SerialNumber: 0001
|
||||
|
||||
The debug device works now. You can use any communication or debugging
|
||||
program to talk between the host and the target.
|
||||
|
|
|
|||
|
|
@ -321,6 +321,6 @@ linux-usb-devel Mailing List Archives:
|
|||
http://marc.theaimsgroup.com/?l=linux-usb-devel
|
||||
|
||||
Programming Guide for Linux USB Device Drivers:
|
||||
http://usb.cs.tum.edu/usbdoc
|
||||
http://lmu.web.psi.ch/docu/manuals/software_manuals/linux_sl/usb_linux_programming_guide.pdf
|
||||
|
||||
USB Home Page: http://www.usb.org
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Fault injection capabilities infrastructure
|
||||
===========================================
|
||||
|
||||
See also drivers/md/faulty.c and "every_nth" module option for scsi_debug.
|
||||
See also drivers/md/md-faulty.c and "every_nth" module option for scsi_debug.
|
||||
|
||||
|
||||
Available fault injection capabilities
|
||||
|
|
|
|||
|
|
@ -49,12 +49,10 @@ sb=n Use alternate superblock at this location.
|
|||
|
||||
user_xattr Enable "user." POSIX Extended Attributes
|
||||
(requires CONFIG_EXT2_FS_XATTR).
|
||||
See also http://acl.bestbits.at
|
||||
nouser_xattr Don't support "user." extended attributes.
|
||||
|
||||
acl Enable POSIX Access Control Lists support
|
||||
(requires CONFIG_EXT2_FS_POSIX_ACL).
|
||||
See also http://acl.bestbits.at
|
||||
noacl Don't support POSIX ACLs.
|
||||
|
||||
nobh Do not attach buffer_heads to file pagecache.
|
||||
|
|
|
|||
|
|
@ -202,15 +202,14 @@ inode_readahead_blks=n This tuning parameter controls the maximum
|
|||
the buffer cache. The default value is 32 blocks.
|
||||
|
||||
nouser_xattr Disables Extended User Attributes. See the
|
||||
attr(5) manual page and http://acl.bestbits.at/
|
||||
for more information about extended attributes.
|
||||
attr(5) manual page for more information about
|
||||
extended attributes.
|
||||
|
||||
noacl This option disables POSIX Access Control List
|
||||
support. If ACL support is enabled in the kernel
|
||||
configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL is
|
||||
enabled by default on mount. See the acl(5) manual
|
||||
page and http://acl.bestbits.at/ for more information
|
||||
about acl.
|
||||
page for more information about acl.
|
||||
|
||||
bsddf (*) Make 'df' act like BSD.
|
||||
minixdf Make 'df' act like Minix.
|
||||
|
|
|
|||
|
|
@ -344,4 +344,4 @@ the following:
|
|||
characters in the final slot are set to Unicode 0xFFFF.
|
||||
|
||||
Finally, note that the extended name is stored in Unicode. Each Unicode
|
||||
character takes two bytes.
|
||||
character takes either two or four bytes, UTF-16LE encoded.
|
||||
|
|
|
|||
|
|
@ -17,13 +17,16 @@ i2c-10, ...). All 256 minor device numbers are reserved for i2c.
|
|||
C example
|
||||
=========
|
||||
|
||||
So let's say you want to access an i2c adapter from a C program. The
|
||||
first thing to do is "#include <linux/i2c-dev.h>". Please note that
|
||||
there are two files named "i2c-dev.h" out there, one is distributed
|
||||
with the Linux kernel and is meant to be included from kernel
|
||||
driver code, the other one is distributed with i2c-tools and is
|
||||
meant to be included from user-space programs. You obviously want
|
||||
the second one here.
|
||||
So let's say you want to access an i2c adapter from a C program.
|
||||
First, you need to include these two headers:
|
||||
|
||||
#include <linux/i2c-dev.h>
|
||||
#include <i2c/smbus.h>
|
||||
|
||||
(Please note that there are two files named "i2c-dev.h" out there. One is
|
||||
distributed with the Linux kernel and the other one is included in the
|
||||
source tree of i2c-tools. They used to be different in content but since 2012
|
||||
they're identical. You should use "linux/i2c-dev.h").
|
||||
|
||||
Now, you have to decide which adapter you want to access. You should
|
||||
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
|
||||
|
|
|
|||
|
|
@ -13,6 +13,18 @@ documents into a coherent whole. Please note that improvements to the
|
|||
documentation are welcome; join the linux-doc list at vger.kernel.org if
|
||||
you want to help out.
|
||||
|
||||
Licensing documentation
|
||||
-----------------------
|
||||
|
||||
The following describes the license of the Linux kernel source code
|
||||
(GPLv2), how to properly mark the license of individual files in the source
|
||||
tree, as well as links to the full license text.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
process/license-rules.rst
|
||||
|
||||
User-oriented documentation
|
||||
---------------------------
|
||||
|
||||
|
|
@ -52,6 +64,7 @@ merged much easier.
|
|||
dev-tools/index
|
||||
doc-guide/index
|
||||
kernel-hacking/index
|
||||
maintainer/index
|
||||
|
||||
Kernel API documentation
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -77,6 +77,27 @@ applicable everywhere (see syntax).
|
|||
Optionally, dependencies only for this default value can be added with
|
||||
"if".
|
||||
|
||||
The default value deliberately defaults to 'n' in order to avoid bloating the
|
||||
build. With few exceptions, new config options should not change this. The
|
||||
intent is for "make oldconfig" to add as little as possible to the config from
|
||||
release to release.
|
||||
|
||||
Note:
|
||||
Things that merit "default y/m" include:
|
||||
|
||||
a) A new Kconfig option for something that used to always be built
|
||||
should be "default y".
|
||||
|
||||
b) A new gatekeeping Kconfig option that hides/shows other Kconfig
|
||||
options (but does not generate any code of its own), should be
|
||||
"default y" so people will see those other options.
|
||||
|
||||
c) Sub-driver behavior or similar options for a driver that is
|
||||
"default n". This allows you to provide sane defaults.
|
||||
|
||||
d) Hardware or infrastructure that everybody expects, such as CONFIG_NET
|
||||
or CONFIG_BLOCK. These are rare exceptions.
|
||||
|
||||
- type definition + default value:
|
||||
"def_bool"/"def_tristate" <expr> ["if" <expr>]
|
||||
This is a shorthand notation for a type definition plus a value.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue