mirror of
https://github.com/t2linux/kernel.git
synced 2026-04-30 13:48:59 -07:00
Merge tag 'docs-4.19' of git://git.lwn.net/linux
Pull documentation update from Jonathan Corbet: "This was a moderately busy cycle for docs, with the usual collection of small fixes and updates. We also have new ktime_get_*() docs from Arnd, some kernel-doc fixes, a new set of Italian translations (non so se vale la pena, ma non fa male - speriamo bene), and some extensive early memory-management documentation improvements from Mike Rapoport" * tag 'docs-4.19' of git://git.lwn.net/linux: (52 commits) Documentation: corrections to console/console.txt Documentation: add ioctl number entry for v4l2-subdev.h Remove gendered language from management style documentation scripts/kernel-doc: Escape all literal braces in regexes docs/mm: add description of boot time memory management docs/mm: memblock: add overview documentation docs/mm: memblock: add kernel-doc description for memblock types docs/mm: memblock: add kernel-doc comments for memblock_add[_node] docs/mm: memblock: update kernel-doc comments mm/memblock: add a name for memblock flags enumeration docs/mm: bootmem: add overview documentation docs/mm: bootmem: add kernel-doc description of 'struct bootmem_data' docs/mm: bootmem: fix kernel-doc warnings docs/mm: nobootmem: fixup kernel-doc comments mm/bootmem: drop duplicated kernel-doc comments Documentation: vm.txt: Adding 'nr_hugepages_mempolicy' parameter description. doc:it_IT: translation for kernel-hacking docs: Fix the reference labels in Locking.rst doc: tracing: Fix a typo of trace_stat mm: Introduce new type vm_fault_t ...
This commit is contained in:
Linus Torvalds
@@ -1,3 +1,5 @@
|
||||
.. _readme:
|
||||
|
||||
Linux kernel release 4.x <http://kernel.org/>
|
||||
=============================================
|
||||
|
||||
|
||||
@@ -4136,6 +4136,8 @@
|
||||
This parameter controls whether the Speculative Store
|
||||
Bypass optimization is used.
|
||||
|
||||
On x86 the options are:
|
||||
|
||||
on - Unconditionally disable Speculative Store Bypass
|
||||
off - Unconditionally enable Speculative Store Bypass
|
||||
auto - Kernel detects whether the CPU model contains an
|
||||
@@ -4151,12 +4153,20 @@
|
||||
seccomp - Same as "prctl" above, but all seccomp threads
|
||||
will disable SSB unless they explicitly opt out.
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spec_store_bypass_disable=auto.
|
||||
|
||||
Default mitigations:
|
||||
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
|
||||
|
||||
On powerpc the options are:
|
||||
|
||||
on,auto - On Power8 and Power9 insert a store-forwarding
|
||||
barrier on kernel entry and exit. On Power7
|
||||
perform a software flush on kernel entry and
|
||||
exit.
|
||||
off - No action.
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spec_store_bypass_disable=auto.
|
||||
|
||||
spia_io_base= [HW,MTD]
|
||||
spia_fio_base=
|
||||
spia_pedr=
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Console Drivers
|
||||
===============
|
||||
|
||||
The linux kernel has 2 general types of console drivers. The first type is
|
||||
The Linux kernel has 2 general types of console drivers. The first type is
|
||||
assigned by the kernel to all the virtual consoles during the boot process.
|
||||
This type will be called 'system driver', and only one system driver is allowed
|
||||
to exist. The system driver is persistent and it can never be unloaded, though
|
||||
@@ -17,10 +17,11 @@ of driver occupying the consoles.) They can only take over the console that is
|
||||
occupied by the system driver. In the same token, if the modular driver is
|
||||
released by the console, the system driver will take over.
|
||||
|
||||
Modular drivers, from the programmer's point of view, has to call:
|
||||
Modular drivers, from the programmer's point of view, have to call:
|
||||
|
||||
do_take_over_console() - load and bind driver to console layer
|
||||
give_up_console() - unload driver, it will only work if driver is fully unbond
|
||||
give_up_console() - unload driver; it will only work if driver
|
||||
is fully unbound
|
||||
|
||||
In newer kernels, the following are also available:
|
||||
|
||||
@@ -56,7 +57,7 @@ What do these files signify?
|
||||
cat /sys/class/vtconsole/vtcon0/name
|
||||
(S) VGA+
|
||||
|
||||
'(S)' stands for a (S)ystem driver, ie, it cannot be directly
|
||||
'(S)' stands for a (S)ystem driver, i.e., it cannot be directly
|
||||
commanded to bind or unbind
|
||||
|
||||
'VGA+' is the name of the driver
|
||||
@@ -89,7 +90,7 @@ driver, make changes, recompile, reload and rebind the driver without any need
|
||||
for rebooting the kernel. For regular users who may want to switch from
|
||||
framebuffer console to VGA console and vice versa, this feature also makes
|
||||
this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
|
||||
for more details).
|
||||
for more details.)
|
||||
|
||||
Notes for developers:
|
||||
=====================
|
||||
@@ -110,8 +111,8 @@ In order for binding to and unbinding from the console to properly work,
|
||||
console drivers must follow these guidelines:
|
||||
|
||||
1. All drivers, except system drivers, must call either do_register_con_driver()
|
||||
or do_take_over_console(). do_register_con_driver() will just add the driver to
|
||||
the console's internal list. It won't take over the
|
||||
or do_take_over_console(). do_register_con_driver() will just add the driver
|
||||
to the console's internal list. It won't take over the
|
||||
console. do_take_over_console(), as it name implies, will also take over (or
|
||||
bind to) the console.
|
||||
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
===========================
|
||||
Boot time memory management
|
||||
===========================
|
||||
|
||||
Early system initialization cannot use "normal" memory management
|
||||
simply because it is not set up yet. But there is still need to
|
||||
allocate memory for various data structures, for instance for the
|
||||
physical page allocator. To address this, a specialized allocator
|
||||
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
|
||||
introduced. Several years later PowerPC developers added a "Logical
|
||||
Memory Blocks" allocator, which was later adopted by other
|
||||
architectures and renamed to :ref:`memblock <memblock>`. There is also
|
||||
a compatibility layer called `nobootmem` that translates bootmem
|
||||
allocation interfaces to memblock calls.
|
||||
|
||||
The selection of the early allocator is done using
|
||||
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
|
||||
configuration options. These options are enabled or disabled
|
||||
statically by the architectures' Kconfig files.
|
||||
|
||||
* Architectures that rely only on bootmem select
|
||||
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
|
||||
* The users of memblock with the nobootmem compatibility layer set
|
||||
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
* And for those that use both memblock and bootmem the configuration
|
||||
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
|
||||
Whichever allocator is used, it is the responsibility of the
|
||||
architecture specific initialization to set it up in
|
||||
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
|
||||
|
||||
Once the early memory management is available it offers a variety of
|
||||
functions and macros for memory allocations. The allocation request
|
||||
may be directed to the first (and probably the only) node or to a
|
||||
particular node in a NUMA system. There are API variants that panic
|
||||
when an allocation fails and those that don't. And more recent and
|
||||
advanced memblock even allows controlling its own behaviour.
|
||||
|
||||
.. _bootmem:
|
||||
|
||||
Bootmem
|
||||
=======
|
||||
|
||||
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
|
||||
Memory Manager" `book`_)
|
||||
|
||||
.. _book: https://www.kernel.org/doc/gorman/
|
||||
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:doc: bootmem overview
|
||||
|
||||
.. _memblock:
|
||||
|
||||
Memblock
|
||||
========
|
||||
|
||||
.. kernel-doc:: mm/memblock.c
|
||||
:doc: memblock overview
|
||||
|
||||
|
||||
Functions and structures
|
||||
========================
|
||||
|
||||
Common API
|
||||
----------
|
||||
|
||||
The functions that are described in this section are available
|
||||
regardless of what early memory manager is enabled.
|
||||
|
||||
.. kernel-doc:: mm/nobootmem.c
|
||||
|
||||
Bootmem specific API
|
||||
--------------------
|
||||
|
||||
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
|
||||
|
||||
.. kernel-doc:: include/linux/bootmem.h
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:nodocs:
|
||||
|
||||
Memblock specific API
|
||||
---------------------
|
||||
|
||||
Here is the description of memblock data structures, functions and
|
||||
macros. Some of them are actually internal, but since they are
|
||||
documented it would be silly to omit them. Besides, reading the
|
||||
descriptions for the internal functions can help to understand what
|
||||
really happens under the hood.
|
||||
|
||||
.. kernel-doc:: include/linux/memblock.h
|
||||
.. kernel-doc:: mm/memblock.c
|
||||
:nodocs:
|
||||
@@ -76,4 +76,6 @@ Functions and structures
|
||||
========================
|
||||
|
||||
.. kernel-doc:: include/linux/idr.h
|
||||
:functions:
|
||||
.. kernel-doc:: lib/idr.c
|
||||
:functions:
|
||||
|
||||
@@ -28,6 +28,8 @@ Core utilities
|
||||
printk-formats
|
||||
circular-buffers
|
||||
gfp_mask-from-fs-io
|
||||
timekeeping
|
||||
boot-time-mm
|
||||
|
||||
Interfaces for kernel debugging
|
||||
===============================
|
||||
|
||||
@@ -0,0 +1,185 @@
|
||||
ktime accessors
|
||||
===============
|
||||
|
||||
Device drivers can read the current time using ktime_get() and the many
|
||||
related functions declared in linux/timekeeping.h. As a rule of thumb,
|
||||
using an accessor with a shorter name is preferred over one with a longer
|
||||
name if both are equally fit for a particular use case.
|
||||
|
||||
Basic ktime_t based interfaces
|
||||
------------------------------
|
||||
|
||||
The recommended simplest form returns an opaque ktime_t, with variants
|
||||
that return time for different clock references:
|
||||
|
||||
|
||||
.. c:function:: ktime_t ktime_get( void )
|
||||
|
||||
CLOCK_MONOTONIC
|
||||
|
||||
Useful for reliable timestamps and measuring short time intervals
|
||||
accurately. Starts at system boot time but stops during suspend.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_boottime( void )
|
||||
|
||||
CLOCK_BOOTTIME
|
||||
|
||||
Like ktime_get(), but does not stop when suspended. This can be
|
||||
used e.g. for key expiration times that need to be synchronized
|
||||
with other machines across a suspend operation.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_real( void )
|
||||
|
||||
CLOCK_REALTIME
|
||||
|
||||
Returns the time in relative to the UNIX epoch starting in 1970
|
||||
using the Coordinated Universal Time (UTC), same as gettimeofday()
|
||||
user space. This is used for all timestamps that need to
|
||||
persist across a reboot, like inode times, but should be avoided
|
||||
for internal uses, since it can jump backwards due to a leap
|
||||
second update, NTP adjustment settimeofday() operation from user
|
||||
space.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_clocktai( void )
|
||||
|
||||
CLOCK_TAI
|
||||
|
||||
Like ktime_get_real(), but uses the International Atomic Time (TAI)
|
||||
reference instead of UTC to avoid jumping on leap second updates.
|
||||
This is rarely useful in the kernel.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_raw( void )
|
||||
|
||||
CLOCK_MONOTONIC_RAW
|
||||
|
||||
Like ktime_get(), but runs at the same rate as the hardware
|
||||
clocksource without (NTP) adjustments for clock drift. This is
|
||||
also rarely needed in the kernel.
|
||||
|
||||
nanosecond, timespec64, and second output
|
||||
-----------------------------------------
|
||||
|
||||
For all of the above, there are variants that return the time in a
|
||||
different format depending on what is required by the user:
|
||||
|
||||
.. c:function:: u64 ktime_get_ns( void )
|
||||
u64 ktime_get_boottime_ns( void )
|
||||
u64 ktime_get_real_ns( void )
|
||||
u64 ktime_get_tai_ns( void )
|
||||
u64 ktime_get_raw_ns( void )
|
||||
|
||||
Same as the plain ktime_get functions, but returning a u64 number
|
||||
of nanoseconds in the respective time reference, which may be
|
||||
more convenient for some callers.
|
||||
|
||||
.. c:function:: void ktime_get_ts64( struct timespec64 * )
|
||||
void ktime_get_boottime_ts64( struct timespec64 * )
|
||||
void ktime_get_real_ts64( struct timespec64 * )
|
||||
void ktime_get_clocktai_ts64( struct timespec64 * )
|
||||
void ktime_get_raw_ts64( struct timespec64 * )
|
||||
|
||||
Same above, but returns the time in a 'struct timespec64', split
|
||||
into seconds and nanoseconds. This can avoid an extra division
|
||||
when printing the time, or when passing it into an external
|
||||
interface that expects a 'timespec' or 'timeval' structure.
|
||||
|
||||
.. c:function:: time64_t ktime_get_seconds( void )
|
||||
time64_t ktime_get_boottime_seconds( void )
|
||||
time64_t ktime_get_real_seconds( void )
|
||||
time64_t ktime_get_clocktai_seconds( void )
|
||||
time64_t ktime_get_raw_seconds( void )
|
||||
|
||||
Return a coarse-grained version of the time as a scalar
|
||||
time64_t. This avoids accessing the clock hardware and rounds
|
||||
down the seconds to the full seconds of the last timer tick
|
||||
using the respective reference.
|
||||
|
||||
Coarse and fast_ns access
|
||||
-------------------------
|
||||
|
||||
Some additional variants exist for more specialized cases:
|
||||
|
||||
.. c:function:: ktime_t ktime_get_coarse_boottime( void )
|
||||
ktime_t ktime_get_coarse_real( void )
|
||||
ktime_t ktime_get_coarse_clocktai( void )
|
||||
ktime_t ktime_get_coarse_raw( void )
|
||||
|
||||
.. c:function:: void ktime_get_coarse_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_boottime_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_real_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_clocktai_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_raw_ts64( struct timespec64 * )
|
||||
|
||||
These are quicker than the non-coarse versions, but less accurate,
|
||||
corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
|
||||
in user space, along with the equivalent boottime/tai/raw
|
||||
timebase not available in user space.
|
||||
|
||||
The time returned here corresponds to the last timer tick, which
|
||||
may be as much as 10ms in the past (for CONFIG_HZ=100), same as
|
||||
reading the 'jiffies' variable. These are only useful when called
|
||||
in a fast path and one still expects better than second accuracy,
|
||||
but can't easily use 'jiffies', e.g. for inode timestamps.
|
||||
Skipping the hardware clock access saves around 100 CPU cycles
|
||||
on most modern machines with a reliable cycle counter, but
|
||||
up to several microseconds on older hardware with an external
|
||||
clocksource.
|
||||
|
||||
.. c:function:: u64 ktime_get_mono_fast_ns( void )
|
||||
u64 ktime_get_raw_fast_ns( void )
|
||||
u64 ktime_get_boot_fast_ns( void )
|
||||
u64 ktime_get_real_fast_ns( void )
|
||||
|
||||
These variants are safe to call from any context, including from
|
||||
a non-maskable interrupt (NMI) during a timekeeper update, and
|
||||
while we are entering suspend with the clocksource powered down.
|
||||
This is useful in some tracing or debugging code as well as
|
||||
machine check reporting, but most drivers should never call them,
|
||||
since the time is allowed to jump under certain conditions.
|
||||
|
||||
Deprecated time interfaces
|
||||
--------------------------
|
||||
|
||||
Older kernels used some other interfaces that are now being phased out
|
||||
but may appear in third-party drivers being ported here. In particular,
|
||||
all interfaces returning a 'struct timeval' or 'struct timespec' have
|
||||
been replaced because the tv_sec member overflows in year 2038 on 32-bit
|
||||
architectures. These are the recommended replacements:
|
||||
|
||||
.. c:function:: void ktime_get_ts( struct timespec * )
|
||||
|
||||
Use ktime_get() or ktime_get_ts64() instead.
|
||||
|
||||
.. c:function:: struct timeval do_gettimeofday( void )
|
||||
struct timespec getnstimeofday( void )
|
||||
struct timespec64 getnstimeofday64( void )
|
||||
void ktime_get_real_ts( struct timespec * )
|
||||
|
||||
ktime_get_real_ts64() is a direct replacement, but consider using
|
||||
monotonic time (ktime_get_ts64()) and/or a ktime_t based interface
|
||||
(ktime_get()/ktime_get_real()).
|
||||
|
||||
.. c:function:: struct timespec current_kernel_time( void )
|
||||
struct timespec64 current_kernel_time64( void )
|
||||
struct timespec get_monotonic_coarse( void )
|
||||
struct timespec64 get_monotonic_coarse64( void )
|
||||
|
||||
These are replaced by ktime_get_coarse_real_ts64() and
|
||||
ktime_get_coarse_ts64(). However, A lot of code that wants
|
||||
coarse-grained times can use the simple 'jiffies' instead, while
|
||||
some drivers may actually want the higher resolution accessors
|
||||
these days.
|
||||
|
||||
.. c:function:: struct timespec getrawmonotonic( void )
|
||||
struct timespec64 getrawmonotonic64( void )
|
||||
struct timespec timekeeping_clocktai( void )
|
||||
struct timespec64 timekeeping_clocktai64( void )
|
||||
struct timespec get_monotonic_boottime( void )
|
||||
struct timespec64 get_monotonic_boottime64( void )
|
||||
|
||||
These are replaced by ktime_get_raw()/ktime_get_raw_ts64(),
|
||||
ktime_get_clocktai()/ktime_get_clocktai_ts64() as well
|
||||
as ktime_get_boottime()/ktime_get_boottime_ts64().
|
||||
However, if the particular choice of clock source is not
|
||||
important for the user, consider converting to
|
||||
ktime_get()/ktime_get_ts64() instead for consistency.
|
||||
@@ -156,6 +156,11 @@ Contributing new tests (details)
|
||||
installed by the distro on the system should be the primary focus to be able
|
||||
to find regressions.
|
||||
|
||||
* If a test needs specific kernel config options enabled, add a config file in
|
||||
the test directory to enable them.
|
||||
|
||||
e.g: tools/testing/selftests/android/ion/config
|
||||
|
||||
Test Harness
|
||||
============
|
||||
|
||||
|
||||
@@ -488,14 +488,19 @@ doc: *title*
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
|
||||
:doc: High Definition Audio over HDMI and Display Port
|
||||
|
||||
functions: *function* *[...]*
|
||||
functions: *[ function ...]*
|
||||
Include documentation for each *function* in *source*.
|
||||
If no *function* if specified, the documentaion for all functions
|
||||
and types in the *source* will be included.
|
||||
|
||||
Example::
|
||||
Examples::
|
||||
|
||||
.. kernel-doc:: lib/bitmap.c
|
||||
:functions: bitmap_parselist bitmap_parselist_user
|
||||
|
||||
.. kernel-doc:: lib/idr.c
|
||||
:functions:
|
||||
|
||||
Without options, the kernel-doc directive includes all documentation comments
|
||||
from the source file.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ SYNOPSIS
|
||||
|
||||
\ **parse_headers.pl**\ [<options>] <C_FILE> <OUT_FILE> [<EXCEPTIONS_FILE>]
|
||||
|
||||
Where <options> can be: --debug, --help or --man.
|
||||
Where <options> can be: --debug, --help or --usage.
|
||||
|
||||
|
||||
OPTIONS
|
||||
@@ -133,7 +133,7 @@ For both statements, \ **type**\ can be either one of the following:
|
||||
|
||||
\ **symbol**\
|
||||
|
||||
The ignore or replace statement will apply to the name of enum statements
|
||||
The ignore or replace statement will apply to the name of enum value
|
||||
at C_FILE.
|
||||
|
||||
For replace statements, \ **new_value**\ will automatically use :c:type:
|
||||
|
||||
@@ -28,7 +28,7 @@ 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
|
||||
There's a script that checks for the Sphinx requirements. Please see
|
||||
:ref:`sphinx-pre-install` for further details.
|
||||
|
||||
Most distributions are shipped with Sphinx, but its toolchain is fragile,
|
||||
|
||||
@@ -374,7 +374,7 @@ The nand driver supports three different types of hardware ECC.
|
||||
|
||||
- NAND_ECC_HW8_512
|
||||
|
||||
Hardware ECC generator providing 6 bytes ECC per 512 byte.
|
||||
Hardware ECC generator providing 8 bytes ECC per 512 byte.
|
||||
|
||||
If your hardware generator has a different functionality add it at the
|
||||
appropriate place in nand_base.c
|
||||
@@ -889,7 +889,7 @@ Use these constants to select the ECC algorithm::
|
||||
#define NAND_ECC_HW3_512 3
|
||||
/* Hardware ECC 6 byte ECC per 512 Byte data */
|
||||
#define NAND_ECC_HW6_512 4
|
||||
/* Hardware ECC 6 byte ECC per 512 Byte data */
|
||||
/* Hardware ECC 8 byte ECC per 512 Byte data */
|
||||
#define NAND_ECC_HW8_512 6
|
||||
|
||||
|
||||
|
||||
@@ -532,9 +532,9 @@ More details about quota locking can be found in fs/dquot.c.
|
||||
prototypes:
|
||||
void (*open)(struct vm_area_struct*);
|
||||
void (*close)(struct vm_area_struct*);
|
||||
int (*fault)(struct vm_area_struct*, struct vm_fault *);
|
||||
int (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
||||
int (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
||||
vm_fault_t (*fault)(struct vm_area_struct*, struct vm_fault *);
|
||||
vm_fault_t (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
||||
vm_fault_t (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
||||
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
||||
|
||||
locking rules:
|
||||
|
||||
@@ -870,6 +870,7 @@ Committed_AS: 100056 kB
|
||||
VmallocTotal: 112216 kB
|
||||
VmallocUsed: 428 kB
|
||||
VmallocChunk: 111088 kB
|
||||
HardwareCorrupted: 0 kB
|
||||
AnonHugePages: 49152 kB
|
||||
ShmemHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
@@ -915,6 +916,8 @@ MemAvailable: An estimate of how much memory is available for starting new
|
||||
Dirty: Memory which is waiting to get written back to the disk
|
||||
Writeback: Memory which is actively being written back to the disk
|
||||
AnonPages: Non-file backed pages mapped into userspace page tables
|
||||
HardwareCorrupted: The amount of RAM/memory in KB, the kernel identifies as
|
||||
corrupted.
|
||||
AnonHugePages: Non-file backed huge pages mapped into userspace page tables
|
||||
Mapped: files which have been mmaped, such as libraries
|
||||
Shmem: Total memory used by shared memory (shmem) and tmpfs
|
||||
|
||||
@@ -222,7 +222,7 @@ using debugfs:
|
||||
*/
|
||||
static struct dentry *create_buf_file_handler(const char *filename,
|
||||
struct dentry *parent,
|
||||
int mode,
|
||||
umode_t mode,
|
||||
struct rchan_buf *buf,
|
||||
int *is_global)
|
||||
{
|
||||
@@ -375,7 +375,7 @@ would be very similar:
|
||||
static int subbuf_start(struct rchan_buf *buf,
|
||||
void *subbuf,
|
||||
void *prev_subbuf,
|
||||
unsigned int prev_padding)
|
||||
size_t prev_padding)
|
||||
{
|
||||
if (prev_subbuf)
|
||||
*((unsigned *)prev_subbuf) = prev_padding;
|
||||
|
||||
+6
-20
@@ -3,6 +3,8 @@
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
.. _linux_doc:
|
||||
|
||||
The Linux Kernel documentation
|
||||
==============================
|
||||
|
||||
@@ -113,29 +115,13 @@ subprojects.
|
||||
|
||||
filesystems/ext4/index
|
||||
|
||||
Korean translations
|
||||
-------------------
|
||||
Translations
|
||||
------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:maxdepth: 2
|
||||
|
||||
translations/ko_KR/index
|
||||
|
||||
Chinese translations
|
||||
--------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
translations/zh_CN/index
|
||||
|
||||
Japanese translations
|
||||
---------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
translations/ja_JP/index
|
||||
translations/index
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
@@ -274,6 +274,7 @@ Code Seq#(hex) Include File Comments
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
'v' 00-0F linux/sonypi.h conflict!
|
||||
'v' 00-0F media/v4l2-subdev.h conflict!
|
||||
'v' C0-FF linux/meye.h conflict!
|
||||
'w' all CERN SCI driver
|
||||
'y' 00-1F packet based user level communications
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. _kernel_hacking_hack:
|
||||
|
||||
============================================
|
||||
Unreliable Guide To Hacking The Linux Kernel
|
||||
============================================
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. _kernel_hacking:
|
||||
|
||||
=====================
|
||||
Kernel Hacking Guides
|
||||
=====================
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. _kernel_hacking_lock:
|
||||
|
||||
===========================
|
||||
Unreliable Guide To Locking
|
||||
===========================
|
||||
@@ -177,7 +179,7 @@ perfect world).
|
||||
|
||||
Note that you can also use :c:func:`spin_lock_irq()` or
|
||||
:c:func:`spin_lock_irqsave()` here, which stop hardware interrupts
|
||||
as well: see `Hard IRQ Context <#hardirq-context>`__.
|
||||
as well: see `Hard IRQ Context <#hard-irq-context>`__.
|
||||
|
||||
This works perfectly for UP as well: the spin lock vanishes, and this
|
||||
macro simply becomes :c:func:`local_bh_disable()`
|
||||
@@ -228,7 +230,7 @@ The Same Softirq
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The same softirq can run on the other CPUs: you can use a per-CPU array
|
||||
(see `Per-CPU Data <#per-cpu>`__) for better performance. If you're
|
||||
(see `Per-CPU Data <#per-cpu-data>`__) for better performance. If you're
|
||||
going so far as to use a softirq, you probably care about scalable
|
||||
performance enough to justify the extra complexity.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user