| /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 …]
|
| /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 | 16 The Concept of CPU Performance Scaling
19 The majority of modern processors are capable of operating in a number of
22 the higher the clock frequency and the higher the voltage, the more instructions
23 can be retired by the CPU over a unit of time, but also the higher the clock
24 frequency and the higher the voltage, the more energy is consumed over a unit of
25 time (or the more power is drawn) by the CPU in the given P-state. Therefore
26 there is a natural tradeoff between the CPU capacity (the number of instructions
27 that can be executed over a unit of time) and the power drawn by the CPU.
29 In some situations it is desirable or even necessary to run the program as fast
30 as possible and then there is no reason to use any P-states different from the
[all …]
|
| /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 …]
|
| /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 …]
|
| /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 …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | dm-integrity.rst | 5 The dm-integrity target emulates a block device that has additional
9 writing the sector and the integrity tag must be atomic - i.e. in case of
12 To guarantee write atomicity, the dm-integrity target uses journal, it
13 writes sector data and integrity tags into a journal, commits the journal
14 and then copies the data and integrity tags to their respective location.
16 The dm-integrity target can be used with the dm-crypt target - in this
17 situation the dm-crypt target creates the integrity data and passes them
18 to the dm-integrity target via bio_integrity_payload attached to the bio.
19 In this mode, the dm-crypt and dm-integrity targets provide authenticated
20 disk encryption - if the attacker modifies the encrypted device, an I/O
[all …]
|
| /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 …]
|
| /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 …]
|
| /Documentation/power/ |
| D | userland-swsusp.rst | 7 First, the warnings at the beginning of swsusp.txt still apply.
9 Second, you should read the FAQ in swsusp.txt _now_ if you have not
12 Now, to use the userland interface for software suspend you need special
13 utilities that will read/write the system memory snapshot from/to the
18 The interface consists of a character device providing the open(),
20 commands defined in include/linux/suspend_ioctls.h . The major and minor
21 numbers of the device are, respectively, 10 and 231, and they can
24 The device can be open either for reading or for writing. If open for
25 reading, it is considered to be in the suspend mode. Otherwise it is
26 assumed to be in the resume mode. The device cannot be open for simultaneous
[all …]
|
| D | pm_qos_interface.rst | 7 one of the parameters.
11 2. the per-device PM QoS framework provides the API to manage the per-device latency
25 The infrastructure exposes multiple misc device nodes one per implemented
26 parameter. The set of parameters implement is defined by pm_qos_power_init()
27 and pm_qos_params.h. This is done because having the available parameters
32 an aggregated target value. The aggregated target value is updated with
33 changes to the request list or elements of the list. Typically the
34 aggregated target value is simply the max or min of the request values held
35 in the parameter list elements.
36 Note: the aggregated target value is implemented as an atomic variable so that
[all …]
|
| /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 …]
|
| D | z8530book.rst | 10 The Z85x30 family synchronous/asynchronous controller chips are used on
11 a large number of cheap network interface cards. The kernel provides a
15 The current driver only support synchronous operation. Merging the
18 project for Linux post the 2.4 release
23 The Z85230 driver layer can drive Z8530, Z85C30 and Z85230 devices in
25 on the chip (each chip has two channels).
27 The PIO synchronous mode supports the most common Z8530 wiring. Here the
28 chip is interface to the I/O and interrupt facilities of the host
29 machine but not to the DMA subsystem. When running PIO the Z8530 has
34 The DMA mode supports the chip when it is configured to use dual DMA
[all …]
|
| D | lapb-module.txt | 1 The Linux LAPB Module Interface 1.3
7 The LAPB module will be a separately compiled module for use by any parts of
8 the Linux operating system that require a LAPB service. This document
9 defines the interfaces to, and the services provided by this module. The
10 term module in this context does not imply that the LAPB module is a
11 separately loadable module, although it may be. The term module is used in
14 The interface to the LAPB module consists of functions to the module,
15 callbacks from the module to indicate important state changes, and
16 structures for getting and setting information about the module.
21 Probably the most important structure is the skbuff structure for holding
[all …]
|
| D | 6pack.txt | 1 This is the 6pack-mini-HOWTO, written by
10 1. What is 6pack, and what are the advantages to KISS?
12 6pack is a transmission protocol for data exchange between the PC and
13 the TNC over a serial line. It can be used as an alternative to KISS.
16 - The PC is given full control over the radio
17 channel. Special control data is exchanged between the PC and the TNC so
18 that the PC knows at any time if the TNC is receiving data, if a TNC
19 buffer underrun or overrun has occurred, if the PTT is
22 important event. This helps to improve the channel access and timing
23 algorithms as everything is computed in the PC. It would even be possible
[all …]
|
| /Documentation/timers/ |
| D | highres.rst | 5 Further information can be found in the paper of the OLS 2006 talk "hrtimers
6 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
7 be found on the OLS website:
10 The slides to this talk are available from:
13 The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
14 changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the
15 design of the Linux time(r) system before hrtimers and other building blocks
18 Note: the paper and the slides are talking about "clock event source", while we
19 switched to the name "clock event devices" in meantime.
21 The design contains the following basic building blocks:
[all …]
|
| /Documentation/media/uapi/v4l/ |
| D | selection-api-configuration.rst | 2 .. document under the terms of the GNU Free Documentation License,
3 .. Version 1.1 or any later version published by the Free Software
5 .. and no Back-Cover Texts. A copy of the license is included at
14 Applications can use the :ref:`selection API <VIDIOC_G_SELECTION>` to
20 factors, or have different scaling abilities in the horizontal and
21 vertical directions. Also it may not support scaling at all. At the same
22 time the cropping/composing rectangles may have to be aligned, and both
23 the source and the sink may have arbitrary upper and lower size limits.
24 Therefore, as usual, drivers are expected to adjust the requested
25 parameters and return the actual values selected. An application can
[all …]
|
| D | dev-decoder.rst | 9 A stateful video decoder takes complete chunks of the bytestream (e.g. Annex-B
11 display order. The decoder is expected not to require any additional information
12 from the client to process these buffers.
14 Performing software parsing, processing etc. of the stream in the driver in
16 operations are needed, use of the Stateless Video Decoder Interface (in
22 1. The general V4L2 API rules apply if not specified in this document
25 2. The meaning of words "must", "may", "should", etc. is as per `RFC
36 depending on decoder capabilities and following the general V4L2 guidelines.
41 7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE``
50 the destination buffer queue; for decoders, the queue of buffers containing
[all …]
|
| D | dev-subdev.rst | 2 .. document under the terms of the GNU Free Documentation License,
3 .. Version 1.1 or any later version published by the Free Software
5 .. and no Back-Cover Texts. A copy of the license is included at
16 The complex nature of V4L2 devices, where hardware is often made of
18 controlled way, leads to complex V4L2 drivers. The drivers usually
19 reflect the hardware model in software, and model the different hardware
22 V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
23 implements the media device API, they will automatically inherit from
24 media entities. Applications will be able to enumerate the sub-devices
25 and discover the hardware topology using the media entities, pads and
[all …]
|
| /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 …]
|
| /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 …]
|
| /Documentation/networking/device_drivers/toshiba/ |
| D | spider_net.txt | 2 The Spidernet Device Driver
11 This document sketches the structure of portions of the spidernet
12 device driver in the Linux kernel tree. The spidernet is a gigabit
13 ethernet device built into the Toshiba southbridge commonly used
14 in the SONY Playstation 3 and the IBM QS20 Cell blade.
16 The Structure of the RX Ring.
18 The receive (RX) ring is a circular linked list of RX descriptors,
19 together with three pointers into the ring that are used to manage its
22 The elements of the ring are called "descriptors" or "descrs"; they
23 describe the received data. This includes a pointer to a buffer
[all …]
|
| /Documentation/watchdog/ |
| D | watchdog-kernel-api.rst | 2 The Linux WatchDog Timer Driver Core kernel API
12 It also does not describe the API which can be used by user space to communicate
13 with a WatchDog Timer. If you want to know this then please read the following
16 So what does this document describe? It describes the API that can be used by
17 WatchDog Timer Drivers that want to use the WatchDog Timer Driver Core
19 the same code does not have to be reproduced each time. This also means that
20 a watchdog timer driver then only needs to provide the different routines
21 (operations) that control the watchdog timer (WDT).
23 The API
25 Each watchdog timer driver that wants to use the WatchDog Timer Driver Core
[all …]
|
| /Documentation/ |
| D | robust-futex-ABI.txt | 2 The robust futex ABI
11 The interesting data as to what futexes a thread is holding is kept on a
13 are taken and dropped, without kernel intervention. The only additional
17 1) a one time call, per thread, to tell the kernel where its list of
20 by the exiting thread.
22 The existing normal futexes already provide a "Fast Userspace Locking"
25 threads in the kernel. Options on the sys_futex(2) system call support
26 waiting on a particular futex, and waking up the next waiter on a
29 For robust_futexes to work, the user code (typically in a library such
30 as glibc linked with the application) has to manage and place the
[all …]
|
| D | IPMI.txt | 2 The Linux IPMI Driver
7 The Intelligent Platform Management Interface, or IPMI, is a
9 It provides for dynamic discovery of sensors in the system and the
10 ability to monitor the sensors and be informed when the sensor's
17 management software that can use the IPMI system.
19 This document describes how to use the IPMI driver for Linux. If you
20 are not familiar with IPMI itself, see the web site at
27 The Linux IPMI driver is modular, which means you have to pick several
29 these are available in the 'Character Devices' menu then the IPMI
35 The message handler does not provide any user-level interfaces.
[all …]
|