| /kernel/linux/linux-4.19/Documentation/scsi/ |
| D | st.txt | 1 This file contains brief information about the SCSI tape driver.
2 The driver is currently maintained by Kai Mäkisara (email
10 The driver is generic, i.e., it does not contain any code tailored
11 to any specific tape drive. The tape parameters can be specified with
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.
20 2. The system manager (root) can define default values for some tape
21 parameters, like block size and density using the MTSETDRVBUFFER ioctl.
[all …]
|
| /kernel/linux/linux-5.10/Documentation/admin-guide/pm/ |
| D | cpuidle.rst | 19 Modern processors are generally able to enter states in which the execution of
21 memory or executed. Those states are the *idle* states of the processor.
23 Since part of the processor hardware is not used in idle states, entering them
24 generally allows power drawn by the processor to be reduced and, in consequence,
28 the idle states of processors for this purpose.
33 CPU idle time management operates on CPUs as seen by the *CPU scheduler* (that
34 is the part of the kernel responsible for the distribution of computational
35 work in the system). In its view, CPUs are *logical* units. That is, they need
42 First, if the whole processor can only follow one sequence of instructions (one
43 program) at a time, it is a CPU. In that case, if the hardware is asked to
[all …]
|
| D | cpufreq.rst | 15 The Concept of CPU Performance Scaling
18 The majority of modern processors are capable of operating in a number of
21 the higher the clock frequency and the higher the voltage, the more instructions
22 can be retired by the CPU over a unit of time, but also the higher the clock
23 frequency and the higher the voltage, the more energy is consumed over a unit of
24 time (or the more power is drawn) by the CPU in the given P-state. Therefore
25 there is a natural tradeoff between the CPU capacity (the number of instructions
26 that can be executed over a unit of time) and the power drawn by the CPU.
28 In some situations it is desirable or even necessary to run the program as fast
29 as possible and then there is no reason to use any P-states different from the
[all …]
|
| /kernel/linux/linux-5.10/Documentation/scsi/ |
| D | st.rst | 4 The SCSI Tape Driver
7 This file contains brief information about the SCSI tape driver.
8 The driver is currently maintained by Kai Mäkisara (email
17 The driver is generic, i.e., it does not contain any code tailored
18 to any specific tape drive. The tape parameters can be specified with
19 one of the following three methods:
21 1. Each user can specify the tape parameters he/she wants to use
24 in a multiuser environment the next user finds the tape parameters in
25 state the previous user left them.
27 2. The system manager (root) can define default values for some tape
[all …]
|
| /kernel/linux/linux-5.10/include/linux/ |
| D | nvme-fc-driver.h | 23 * struct nvmefc_ls_req - Request structure passed from the transport
24 * to the LLDD to perform a NVME-FC LS request and obtain
29 * Used by the nvmet-fc transport (controller) to send
32 * Values set by the requestor prior to calling the LLDD ls_req entrypoint:
39 * @timeout: Maximum amount of time, in seconds, to wait for the LS response.
42 * @private: pointer to memory allocated alongside the ls request structure
43 * that is specifically for the LLDD to use while processing the
44 * request. The length of the buffer corresponds to the
45 * lsrqst_priv_sz value specified in the xxx_template supplied
46 * by the LLDD.
[all …]
|
| /kernel/linux/linux-5.10/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
12 The major difference, however, is that user space can only act as a
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
23 and asynchronous invocations. The user space API call is fully
31 The kernel crypto API is accessible from user space. Currently, the
[all …]
|
| /kernel/linux/linux-4.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
12 The major difference, however, is that user space can only act as a
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
23 and asynchronous invocations. The user space API call is fully
31 The kernel crypto API is accessible from user space. Currently, the
[all …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.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 …]
|
| /kernel/linux/linux-4.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
17 The reason that this is such a concern is that XFS allows multiple separate
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.
[all …]
|
| /kernel/linux/linux-4.19/Documentation/admin-guide/pm/ |
| D | cpufreq.rst | 12 The Concept of CPU Performance Scaling
15 The majority of modern processors are capable of operating in a number of
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
[all …]
|
| /kernel/linux/linux-4.19/Documentation/power/ |
| 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 …]
|
| /kernel/linux/linux-5.10/Documentation/power/ |
| D | pci.rst | 7 An overview of concepts and the Linux kernel's interfaces related to PCI power
11 This document only covers the aspects of power management specific to PCI
12 devices. For general description of the kernel's interfaces related to device
31 devices into states in which they draw less power (low-power states) at the
35 completely inactive. However, when it is necessary to use the device once
36 again, it has to be put back into the "fully functional" state (full-power
37 state). This may happen when there are some data for the device to handle or
38 as a result of an external event requiring the device to be active, which may
39 be signaled by the device itself.
41 PCI devices may be put into low-power states in two ways, by using the device
[all …]
|
| /kernel/linux/linux-5.10/Documentation/filesystems/ |
| D | xfs-delayed-logging-design.rst | 11 such as inodes and dquots, are logged in logical format where the details
12 logged are made up of the changes to in-core structures rather than on-disk
14 logged. The reason for these differences is to reduce the amount of log space
17 than any other object (except maybe the superblock buffer) so keeping the
20 The reason that this is such a concern is that XFS allows multiple separate
21 modifications to a single object to be carried in the log at any given time.
22 This allows the log to avoid needing to flush each change to disk before
23 recording a new change to the object. XFS does this via a method called
25 new change to the object is recorded with a *new copy* of all the existing
26 changes in the new transaction that is written to the log.
[all …]
|
| /kernel/linux/linux-5.10/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.
22 The ``userfaultfd`` (aside from registering and unregistering virtual
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
[all …]
|
| /kernel/linux/linux-4.19/Documentation/networking/ |
| D | ppp_generic.txt | 8 The generic PPP driver in linux-2.4 provides an implementation of the
11 * the network interface unit (ppp0 etc.)
12 * the interface to the networking code
15 * the interface to pppd, via a /dev/ppp character device
21 For sending and receiving PPP frames, the generic PPP driver calls on
22 the services of PPP `channels'. A PPP channel encapsulates a
25 has a very simple interface with the generic PPP code: it merely has
33 be linked to each ppp network interface unit. The generic layer is
41 See include/linux/ppp_channel.h for the declaration of the types and
42 functions used to communicate between the generic PPP layer and PPP
[all …]
|
| /kernel/linux/linux-4.19/include/linux/ |
| D | nvme-fc-driver.h | 5 * under the terms and conditions of the GNU General Public License,
6 * version 2, as published by the Free Software Foundation.
8 * This program is distributed in the hope it will be useful, but WITHOUT
9 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
10 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
21 * For FC LLDD's that are the NVME Host role.
39 * Static fields describing the port being registered:
40 * @node_name: FC WWNN for the port
41 * @port_name: FC WWPN for the port
47 * @port_id: FC N_Port_ID currently assigned the port. Upper 8 bits must
[all …]
|
| /kernel/linux/linux-5.10/Documentation/locking/ |
| D | rt-mutex-design.rst | 7 Licensed under the GNU Free Documentation License, Version 1.2
10 This document tries to describe the design of the rtmutex.c implementation.
11 It doesn't describe the reasons why rtmutex.c exists. For that please see
13 that happen without this code, but that is in the concept to understand
14 what the code actually is doing.
16 The goal of this document is to help others understand the priority
17 inheritance (PI) algorithm that is used, as well as reasons for the
18 decisions that were made to implement PI in the manner that was done.
26 most of the time it can't be helped. Anytime a high priority process wants
28 the high priority process must wait until the lower priority process is done
[all …]
|
| /kernel/linux/linux-4.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 …]
|
| /kernel/linux/linux-4.19/LICENSES/preferred/ |
| D | LGPL-2.1 | 5 To use this license in source code, put one of the following SPDX
6 tag/value pairs into a comment according to the placement
7 guidelines in the licensing rules documentation.
24 [This is the first released version of the Lesser GPL. It also counts as
25 the successor of the GNU Library Public License, version 2, hence the
30 The licenses for most software are designed to take away your freedom to
31 share and change it. By contrast, the GNU General Public Licenses are
33 make sure the software is free for all its users.
35 This license, the Lesser General Public License, applies to some specially
36 designated software packages--typically libraries--of the Free Software
[all …]
|
| /kernel/linux/linux-5.10/LICENSES/preferred/ |
| D | LGPL-2.1 | 5 To use this license in source code, put one of the following SPDX
6 tag/value pairs into a comment according to the placement
7 guidelines in the licensing rules documentation.
24 [This is the first released version of the Lesser GPL. It also counts as
25 the successor of the GNU Library Public License, version 2, hence the
30 The licenses for most software are designed to take away your freedom to
31 share and change it. By contrast, the GNU General Public Licenses are
33 make sure the software is free for all its users.
35 This license, the Lesser General Public License, applies to some specially
36 designated software packages--typically libraries--of the Free Software
[all …]
|
| /kernel/linux/linux-4.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
16 of huge pages at mmap() time. The idea is that if there were not enough
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
22 available for page faults in that mapping. The description below attempts to
23 describe how huge page reserve processing is done in the v4.10 kernel.
32 The Data Structures
[all …]
|
| /kernel/linux/linux-5.10/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
16 of huge pages at mmap() time. The idea is that if there were not enough
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
22 available for page faults in that mapping. The description below attempts to
23 describe how huge page reserve processing is done in the v4.10 kernel.
32 The Data Structures
[all …]
|
| /kernel/linux/linux-5.10/Documentation/core-api/ |
| D | debug-objects.rst | 2 The object-lifetime debugging infrastructure
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
[all …]
|
| /kernel/linux/linux-4.19/Documentation/core-api/ |
| D | debug-objects.rst | 2 The object-lifetime debugging infrastructure
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
[all …]
|