| /Linux-v4.19/Documentation/crypto/ |
| D | userspace-if.rst | 7 The concepts of the kernel crypto API visible to kernel space is fully
8 applicable to the user space interface as well. Therefore, the kernel
9 crypto API high level discussion for the in-kernel use cases applies
16 The following covers the user space interface exported by the kernel
19 applications that require cryptographic services from the kernel.
21 Some details of the in-kernel kernel crypto API aspects do not apply to
22 user space, however. This includes the difference between synchronous
31 The kernel crypto API is accessible from user space. Currently, the
42 The interface is provided via socket type using the type AF_ALG. In
43 addition, the setsockopt option type is SOL_ALG. In case the user space
[all …]
|
| D | architecture.rst | 7 The kernel crypto API provides different API calls for the following
24 and message digests. In addition, the kernel crypto API provides
25 numerous "templates" that can be used in conjunction with the single
27 chaining mode, the HMAC mechanism, etc.
54 In these examples, "aes" and "sha1" are the ciphers and all others are
55 the templates.
63 When using the synchronous API operation, the caller invokes a cipher
64 operation which is performed synchronously by the kernel crypto API.
65 That means, the caller waits until the cipher operation completes.
66 Therefore, the kernel crypto API calls work like regular function calls.
[all …]
|
| /Linux-v4.19/Documentation/trace/ |
| D | ring-buffer-design.txt | 7 (dual licensed under the GPL v2)
17 tail - where new writes happen in the ring buffer.
19 head - where new reads happen in the ring buffer.
21 producer - the task that writes into the ring buffer (same as writer)
25 consumer - the task that reads from the buffer (same as reader)
29 reader_page - A page outside the ring buffer used solely (for the most part)
30 by the reader.
32 head_page - a pointer to the page that the reader will use next
34 tail_page - a pointer to the page that will be written to next
36 commit_page - a pointer to the page with the last finished non-nested write.
[all …]
|
| /Linux-v4.19/Documentation/input/ |
| D | multi-touch-protocol.rst | 13 In order to utilize the full power of the new multi-touch and multi-user
15 objects in direct contact with the device surface, is needed. This
16 document describes the multi-touch (MT) protocol which allows kernel
19 The protocol is divided into two types, depending on the capabilities of the
20 hardware. For devices handling anonymous contacts (type A), the protocol
21 describes how to send the raw data for all contacts to the receiver. For
22 devices capable of tracking identifiable contacts (type B), the protocol
33 events. Only the ABS_MT events are recognized as part of a contact
35 applications, the MT protocol can be implemented on top of the ST protocol
39 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
[all …]
|
| /Linux-v4.19/Documentation/acpi/ |
| D | acpi-lid.txt | 1 Special Usage Model of the ACPI Control Method Lid Device
10 control method lid device. To implement this, the AML tables issue
11 Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
12 changed. The _LID control method for the lid device must be implemented to
13 report the "current" state of the lid as either "opened" or "closed".
15 For most platforms, both the _LID method and the lid notifications are
18 taken into account. This document describes the restrictions and the
19 expections of the Linux ACPI lid device driver.
22 1. Restrictions of the returning value of the _LID control method
24 The _LID control method is described to return the "current" lid state.
[all …]
|
| /Linux-v4.19/Documentation/power/ |
| D | userland-swsusp.txt | 4 First, the warnings at the beginning of swsusp.txt still apply.
6 Second, you should read the FAQ in swsusp.txt _now_ if you have not
9 Now, to use the userland interface for software suspend you need special
10 utilities that will read/write the system memory snapshot from/to the
15 The interface consists of a character device providing the open(),
18 numbers of the device are, respectively, 10 and 231, and they can
22 reading, it is considered to be in the suspend mode. Otherwise it is
23 assumed to be in the resume mode. The device cannot be open for simultaneous
24 reading and writing. It is also impossible to have the device open more than
27 Even opening the device has side effects. Data structures are
[all …]
|
| D | pci.txt | 5 An overview of concepts and the Linux kernel's interfaces related to PCI power
9 This document only covers the aspects of power management specific to PCI
10 devices. For general description of the kernel's interfaces related to device
28 devices into states in which they draw less power (low-power states) at the
32 completely inactive. However, when it is necessary to use the device once
33 again, it has to be put back into the "fully functional" state (full-power
34 state). This may happen when there are some data for the device to handle or
35 as a result of an external event requiring the device to be active, which may
36 be signaled by the device itself.
38 PCI devices may be put into low-power states in two ways, by using the device
[all …]
|
| D | pm_qos_interface.txt | 5 one of the parameters.
10 2. the per-device PM QoS framework provides the API to manage the per-device latency
24 and pm_qos_params.h. This is done because having the available parameters
30 changes to the request list or elements of the list. Typically the
31 aggregated target value is simply the max or min of the request values held
32 in the parameter list elements.
33 Note: the aggregated target value is implemented as an atomic variable so that
34 reading the aggregated value does not require any locking mechanism.
37 From kernel mode the use of this interface is simple:
40 Will insert an element into the list for that identified PM QoS class with the
[all …]
|
| D | runtime_pm.txt | 10 at the power management core (PM core) level by means of:
19 * A number of runtime PM fields in the 'power' member of 'struct device' (which
20 is of the type 'struct dev_pm_info', defined in include/linux/pm.h) that can
27 used for carrying out runtime PM operations in such a way that the
28 synchronization between them is taken care of by the PM core. Bus types and
31 The runtime PM callbacks present in 'struct dev_pm_ops', the device runtime PM
32 fields of 'struct dev_pm_info' and the core helper functions provided for
48 are executed by the PM core for the device's subsystem that may be either of
49 the following:
51 1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
[all …]
|
| /Linux-v4.19/Documentation/device-mapper/ |
| D | dm-integrity.txt | 5 writing the sector and the integrity tag must be atomic - i.e. in case of
8 To guarantee write atomicity, the dm-integrity target uses journal, it
9 writes sector data and integrity tags into a journal, commits the journal
10 and then copies the data and integrity tags to their respective location.
12 The dm-integrity target can be used with the dm-crypt target - in this
13 situation the dm-crypt target creates the integrity data and passes them
14 to the dm-integrity target via bio_integrity_payload attached to the bio.
15 In this mode, the dm-crypt and dm-integrity targets provide authenticated
16 disk encryption - if the attacker modifies the encrypted device, an I/O
20 mode it calculates and verifies the integrity tag internally. In this
[all …]
|
| /Linux-v4.19/Documentation/vm/ |
| D | hugetlbfs_reserv.rst | 12 task's address space at page fault time if the VMA indicates huge pages are
13 to be used. If no huge page exists at page fault time, the task is sent
17 huge pages to cover the mapping, the mmap() would fail. This was first
18 done with a simple check in the code at mmap() time to determine if there
19 were enough free huge pages to cover the mapping. Like most things in the
20 kernel, the code has evolved over time. However, the basic idea was to
23 describe how huge page reserve processing is done in the v4.10 kernel.
37 huge pages are only available to the task which reserved them.
38 Therefore, the number of huge pages generally available is computed
41 A reserve map is described by the structure::
[all …]
|
| D | unevictable-lru.rst | 13 This document describes the Linux memory manager's "Unevictable LRU"
14 infrastructure and the use of this to manage several types of "unevictable"
17 The document attempts to provide the overall rationale behind this mechanism
18 and the rationale for some of the design decisions that drove the
19 implementation. The latter design rationale is discussed in the context of an
20 implementation description. Admittedly, one can obtain the implementation
21 details - the "what does it do?" - by reading the code. One hopes that the
22 descriptions below add value by provide the answer to "why does it do that?".
38 will spend a lot of time scanning the LRU lists looking for the small fraction
40 spending 100% of their time in vmscan for hours or days on end, with the system
[all …]
|
| /Linux-v4.19/Documentation/core-api/ |
| D | circular-buffers.rst | 15 (2) Memory barriers for when the producer and the consumer of objects in the
41 (1) A 'head' index - the point at which the producer inserts items into the
44 (2) A 'tail' index - the point at which the consumer finds the next item in
45 the buffer.
47 Typically when the tail pointer is equal to the head pointer, the buffer is
48 empty; and the buffer is full when the head pointer is one less than the tail
51 The head index is incremented when items are added, and the tail index when
52 items are removed. The tail index should never jump the head index, and both
53 indices should be wrapped to 0 when they reach the end of the buffer, thus
54 allowing an infinite amount of data to flow through the buffer.
[all …]
|
| D | debug-objects.rst | 10 debugobjects is a generic infrastructure to track the life time of
11 kernel objects and validate the operations on those.
13 debugobjects is useful to check for the following error patterns:
21 debugobjects is not changing the data structure of the real object so it
28 A kernel subsystem needs to provide a data structure which describes the
29 object type and add calls into the debug code at appropriate places. The
30 data structure to describe the object type needs at minimum the name of
31 the object type. Optional functions can and should be provided to fixup
32 detected problems so the kernel can continue to work and the debug
34 debugging with serial consoles and stack trace transcripts from the
[all …]
|
| /Linux-v4.19/Documentation/watchdog/ |
| D | watchdog-api.txt | 8 Some parts of this document are copied verbatim from the sbc60xxwdt
11 This document describes the state of the Linux 2.4.18 kernel.
15 A Watchdog Timer (WDT) is a hardware circuit that can reset the
19 Usually a userspace daemon will notify the kernel watchdog driver via the
21 regular intervals. When such a notification occurs, the driver will
22 usually tell the hardware watchdog that everything is in order, and
23 that the watchdog should wait for yet another little while to reset
24 the system. If userspace fails (RAM error, kernel bug, whatever), the
25 notifications cease to occur, and the hardware watchdog will reset the
26 system (causing a reboot) after the timeout occurs.
[all …]
|
| /Linux-v4.19/Documentation/admin-guide/pm/ |
| D | cpufreq.rst | 18 the higher the clock frequency and the higher the voltage, the more instructions
19 can be retired by the CPU over a unit of time, but also the higher the clock
20 frequency and the higher the voltage, the more energy is consumed over a unit of
21 time (or the more power is drawn) by the CPU in the given P-state. Therefore
22 there is a natural tradeoff between the CPU capacity (the number of instructions
23 that can be executed over a unit of time) and the power drawn by the CPU.
25 In some situations it is desirable or even necessary to run the program as fast
26 as possible and then there is no reason to use any P-states different from the
27 highest one (i.e. the highest-performance frequency/voltage configuration
29 instructions so quickly and maintaining the highest available CPU capacity for a
[all …]
|
| D | intel_pstate.rst | 13 ``intel_pstate`` is a part of the
14 :doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel
15 (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
18 how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
21 For the processors supported by ``intel_pstate``, the P-state concept is broader
22 than just an operating frequency or an operating performance point (see the
24 information about that). For this reason, the representation of P-states used
25 by ``intel_pstate`` internally follows the hardware specification (for details
27 Volume 3: System Programming Guide <SDM_>`_). However, the ``CPUFreq`` core
29 frequencies are involved in the user space interface exposed by it, so
[all …]
|
| /Linux-v4.19/Documentation/admin-guide/mm/ |
| D | userfaultfd.rst | 10 Userfaults allow the implementation of on-demand paging from userland
12 memory page faults, something otherwise only the kernel code could do.
15 of the PROT_NONE+SIGSEGV trick.
20 Userfaults are delivered and resolved through the userfaultfd syscall.
25 1) read/POLLIN protocol to notify a userland thread of the faults
28 2) various UFFDIO_* ioctls that can manage the virtual memory regions
29 registered in the userfaultfd that allows userland to efficiently
30 resolve the userfaults it receives via 1) or to manage the virtual
31 memory in the background
34 management of mremap/mprotect is that the userfaults in all their
[all …]
|
| D | numa_memory_policy.rst | 10 In the Linux kernel, "memory policy" determines from which node the kernel will
14 document attempts to describe the concepts and APIs of the 2.6 memory policy
19 which is an administrative mechanism for restricting the nodes from which
22 both cpusets and policies are applied to a task, the restrictions of the cpuset
36 this policy is "hard coded" into the kernel. It is the policy
38 one of the more specific policy scopes discussed below. When
39 the system is "up and running", the system default policy will
41 up, the system default policy will be set to interleave
43 not to overload the initial boot node with boot-time
49 by or on behalf of the task that aren't controlled by a more
[all …]
|
| /Linux-v4.19/Documentation/locking/ |
| D | rt-mutex-design.txt | 3 # Licensed under the GNU Free Documentation License, Version 1.2
9 This document tries to describe the design of the rtmutex.c implementation.
10 It doesn't describe the reasons why rtmutex.c exists. For that please see
12 that happen without this code, but that is in the concept to understand
13 what the code actually is doing.
15 The goal of this document is to help others understand the priority
16 inheritance (PI) algorithm that is used, as well as reasons for the
17 decisions that were made to implement PI in the manner that was done.
25 most of the time it can't be helped. Anytime a high priority process wants
27 the high priority process must wait until the lower priority process is done
[all …]
|
| /Linux-v4.19/Documentation/scsi/ |
| D | st.txt | 1 This file contains brief information about the SCSI tape driver.
12 one of the following three methods:
14 1. Each user can specify the tape parameters he/she wants to use
17 in a multiuser environment the next user finds the tape parameters in
18 state the previous user left them.
21 parameters, like block size and density using the MTSETDRVBUFFER ioctl.
23 new tape is loaded into the drive or if writing begins at the
24 beginning of the tape. The second method is applicable if the tape
25 drive performs auto-detection of the tape format well (like some
27 continued using existing format, and the default format is used if
[all …]
|
| /Linux-v4.19/Documentation/filesystems/ |
| D | xfs-delayed-logging-design.txt | 8 such as inodes and dquots, are logged in logical format where the details
9 logged are made up of the changes to in-core structures rather than on-disk
11 logged. The reason for these differences is to reduce the amount of log space
14 than any other object (except maybe the superblock buffer) so keeping the
18 modifications to a single object to be carried in the log at any given time.
19 This allows the log to avoid needing to flush each change to disk before
20 recording a new change to the object. XFS does this via a method called
22 new change to the object is recorded with a *new copy* of all the existing
23 changes in the new transaction that is written to the log.
25 That is, if we have a sequence of changes A through to F, and the object was
[all …]
|
| /Linux-v4.19/Documentation/security/ |
| D | IMA-templates.rst | 9 The original ``ima`` template is fixed length, containing the filedata hash
13 necessary to extend the current version of IMA by defining additional
15 the inode UID/GID or the LSM labels either of the inode and of the process
18 However, the main problem to introduce this feature is that, each time
19 a new template is defined, the functions that generate and display
20 the measurements list would include the code for handling a new format
21 and, thus, would significantly grow over the time.
23 The proposed solution solves this problem by separating the template
24 management from the remaining IMA code. The core of this solution is the
26 which information should be included in the measurement list; a template
[all …]
|
| /Linux-v4.19/Documentation/media/uapi/v4l/ |
| D | dev-subdev.rst | 12 reflect the hardware model in software, and model the different hardware
15 V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
16 implements the media device API, they will automatically inherit from
17 media entities. Applications will be able to enumerate the sub-devices
18 and discover the hardware topology using the media entities, pads and
22 make them directly configurable by applications. When both the
23 sub-device driver and the V4L2 device driver support this, sub-devices
43 Complex devices sometimes implement the same control in different pieces
47 As the V4L2 controls API doesn't support several identical controls in a
48 single device, all but one of the identical controls are hidden.
[all …]
|
| /Linux-v4.19/Documentation/serial/ |
| D | tty.txt | 4 Your guide to the ancient and twisted locking policies of the tty layer and
5 the warped logic behind them. Beware all ye who read on.
11 Line disciplines are registered with tty_register_ldisc() passing the
12 discipline number and the ldisc structure. At the point of registration the
14 the call returns success. If the call returns an error then it won't get
15 called. Do not re-use ldisc numbers as they are part of the userspace ABI
17 After the return the ldisc data has been copied so you may free your own
18 copy of the structure. You must not re-register over the top of the line
19 discipline even with the same data or your computer again will be eaten by
23 In ancient times this always worked. In modern times the function will
[all …]
|
