| /Documentation/process/ |
| D | 4.Coding.rst | 8 code. It is the code which will be examined by other developers and merged
9 (or not) into the mainline tree. So it is the quality of this code which
13 number of ways in which kernel developers can go wrong. Then the focus
14 will shift toward doing things right and the tools which can help in that
28 which does not meet the coding style guidelines. The presence of that code
46 The other trap is to assume that code which is already in the kernel is
56 The coding style document also should not be read as an absolute law which
58 style (a line which becomes far less readable if split to fit within the
85 At a simple level, consider a function which has an argument which is
88 provides. By that time, though, chances are good that the code which
[all …]
|
| D | 1.Intro.rst | 27 :ref:`development_coding` is about the coding process; several pitfalls which
30 which can help to ensure that kernel patches are correct.
56 kernel has evolved into a best-of-breed operating system component which
75 offer this kind of openness, which is a characteristic of the free software
84 evolved its own distinct ways of operating which allow it to function
132 - Code which has been merged into the mainline kernel is available to all
133 Linux users. It will automatically be present on all distributions which
148 Code which is in the mainline, instead, does not require this work as the
151 which has been merged into the mainline has significantly lower
154 - Beyond that, code which is in the kernel will often be improved by other
[all …]
|
| D | 3.Early-stage.rst | 32 misuse of the LSM framework (which is not intended to confer privileges
33 onto processes which they would not otherwise have) and a risk to system
61 - What, exactly, is the problem which needs to be solved?
63 - Who are the users affected by this problem? Which use cases should the
78 - It may well be that the problem is addressed by the kernel in ways which
80 features and capabilities which are not immediately obvious. Not all
83 driver which duplicated an existing driver that the new author had been
84 unaware of. Code which reinvents existing wheels is not only wasteful;
87 - There may be elements of the proposed solution which will not be
96 clear lesson: kernel code which is designed and developed behind closed
[all …]
|
| D | license-rules.rst | 19 which is required to be compatible with the GPL-2.0::
32 The User-space API (UAPI) header files, which describe the interface of
35 which does not extend the GPL requirements to any software which uses it to
37 into any source files which create an executable running on the Linux
43 tools which are used in the context of license compliance.
48 under which the content of the file is contributed. SPDX license
64 possible line in a file which can contain a comment. For the majority
65 of files this is the first line, except for scripts which require the
84 appropriate comment mechanism which the tool accepts shall be used. This
88 there are still older assembler tools which cannot handle C++ style
[all …]
|
| D | volatile-considered-harmful.rst | 11 as a sort of easy atomic variable, which they are not. The use of volatile in
15 to suppress optimization, which is almost never what one really wants to
17 unwanted concurrent access, which is very much a different task. The
21 Like volatile, the kernel primitives which make concurrent access to data
36 change unexpectedly while the_lock is held. Any other code which might
81 - Inline assembly code which changes memory, but which has no other
92 - Pointers to data structures in coherent memory which might be modified
95 indicate which descriptors have been processed, is an example of this
105 they come with a justification which shows that the concurrency issues have
|
| /Documentation/dev-tools/ |
| D | ktap.rst | 11 which don't align with the original TAP specification. Thus, a "Kernel TAP"
16 KTAP test results describe a series of tests (which may be nested: i.e., test
17 can have subtests), each of which can contain both diagnostic data -- e.g., log
31 a couple of places (notably the "Subtest" header), which are described where
37 All KTAP-formatted results begin with a "version line" which specifies which
45 Note that, in KTAP, subtests also begin with a version line, which denotes the
46 start of the nested test results. This differs from TAP14, which uses a
62 which case the test plan may be omitted -- it is strongly recommended one is
75 The result can be either "ok", which indicates the test case passed,
76 or "not ok", which indicates that the test case failed.
[all …]
|
| D | testing-overview.rst | 30 internal structures and functions which aren't exposed to userspace.
33 of the kernel, which can be tested in isolation. This aligns well with the
43 There is a KUnit test style guide which may give further pointers in
51 This makes it easier to write more complicated tests, or tests which need to
54 This means that only kernel functionality which is exposed to userspace somehow
56 work around this, some tests include a companion kernel module which exposes
61 expose an interface to userspace, which can be tested, but not implementation
72 and for finding corner-cases which are not covered by the appropriate test.
74 Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be
79 Documentation/dev-tools/kcov.rst is a feature which can be built in to the
[all …]
|
| /Documentation/timers/ |
| D | hpet.rst | 10 each of which can generate oneshot interrupts and at least one of which has
12 also called "timers", which can be misleading since usually timers are
17 role. Many x86 BIOS writers don't route HPET interrupts at all, which
24 platform code which uses timer 0 or 1 as the main timer to intercept HPET
28 The driver provides a userspace API which resembles the API found in the
|
| D | highres.rst | 6 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
13 The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
37 The main differences to the timer wheel, which holds the armed timer_list type
51 sources, which are registered in the framework and selected on a quality based
53 initializes data structures, which are used by the generic time keeping code to
91 service handler, which is almost inherently hardware dependent.
114 a function pointer in the device description structure, which has to be called
125 The framework adds about 700 lines of code which results in a 2KB increase of
153 which inform hrtimers about availability of new hardware. hrtimers validates
155 switching to high resolution mode. This ensures also that a kernel which is
[all …]
|
| /Documentation/hwmon/ |
| D | peci-cputemp.rst | 7 One of Intel server CPUs listed below which is connected to a PECI bus.
36 This driver implements a generic PECI hwmon feature which provides Digital
50 which is also known as Tcontrol.
51 temp1_crit Provides shutdown temperature of the CPU package which
61 which is also known as Tcontrol.
62 temp2_crit Provides shutdown temperature of the CPU package which
70 package which is also known as Fan Temperature target.
72 temperature at which fans should be engaged.
74 which is same to Tjmax.
|
| /Documentation/arch/x86/ |
| D | mds.rst | 17 MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
20 memory address, which can be exploited under certain conditions. Store
23 buffer is repartitioned which can expose data from one thread to the other.
26 L1 miss situations and to hold data which is returned or sent in response
29 deallocated it can retain the stale data of the preceding operations which
30 can then be forwarded to a faulting or assisting load operation, which can
37 contain stale data from a previous operation which can be forwarded to
38 faulting or assisting loads under certain conditions, which again can be
56 - to have a disclosure gadget which exposes the speculatively accessed
59 - to control the pointer through which the disclosure gadget exposes the
[all …]
|
| D | booting-dt.rst | 9 supports one calling convention which is documented in
12 which requires at least boot protocol 2.09.
18 does not parse / consider data which is already covered by the boot
20 or initrd address. It simply holds information which can not be retrieved
|
| /Documentation/security/ |
| D | sak.rst | 8 An operating system's Secure Attention Key is a security tool which is
10 is an undefeatable way of killing all programs which could be
42 systems which implement C2 level security. This author does not
46 2. On the PC keyboard, SAK kills all applications which have
49 Unfortunately this includes a number of things which you don't
54 You can identify processes which will be killed by SAK with the
67 initscript which launches gpm and changing it thusly:
86 These commands cause **all** daemons which are launched by the
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | mediatek,mt8365-pinctrl.yaml | 83 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
84 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
85 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
86 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
97 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
98 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
99 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
100 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
155 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
156 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
[all …]
|
| /Documentation/ |
| D | atomic_bitops.txt | 33 All RMW atomic operations have a '__' prefixed variant which is non-atomic.
42 which is why the generic version maps to clear_bit_unlock(), see atomic_t.txt.
63 Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics,
64 clear_bit_unlock() which has RELEASE semantics and test_bit_acquire which has
|
| /Documentation/security/tpm/ |
| D | tpm-security.rst | 16 PTT, which is a software TPM running inside a software environment
17 close to the CPU, which are subject to different attacks, but right at
19 hardware TPM, which is the use case discussed here.
25 interposer which is a simple external device that can be installed in
46 which would be an annoying denial of service attack. However, there
56 the PCRs and then send down their own measurements which would
64 on some sort of mechanism for protection which would change over TPM
72 interception which HMAC protection alone cannot protect against, so
80 asymmetric secret must be established which must also be unknown to
82 and storage seeds, which can be used to derive asymmetric keys.
[all …]
|
| /Documentation/filesystems/ |
| D | ext2.rst | 49 resuid=n The user ID which may use the reserved blocks.
50 resgid=n The group ID which may use the reserved blocks.
88 which is decided when the filesystem is created. Smaller blocks mean
100 bitmap and the inode usage bitmap which show which blocks and inodes
107 in the same block group as the inode which contains them.
129 and which OS created it.
144 structure contains pointers to the filesystem blocks which contain the
151 There are some reserved fields which are currently unused in the inode
152 structure and several which are overloaded. One field is reserved for the
156 by the HURD to reference the inode of a program which will be used to
[all …]
|
| D | ocfs2-online-filecheck.rst | 15 Then, a mount option (errors=continue) is introduced, which would return the
23 This effort is to check/fix small issues which may hinder day-to-day operations
31 This feature is not suited for extravagant checks which involve dependency of
43 by the inode number which caused the error. This inode number would be the
50 Here, <devname> indicates the name of OCFS2 volume device which has been already
52 communicate with kernel space, tell which file(inode number) will be checked or
53 fixed. Currently, three operations are supported, which includes checking
97 small linked list buffer which would contain the last (N) inodes
98 fixed/checked, the detailed errors which were fixed/checked are printed in the
|
| /Documentation/driver-api/media/drivers/ |
| D | bttv-devel.rst | 11 completely by the bt8xx chip, which is common on all boards. But
15 bttv-cards.c, which holds the information required for each board.
18 log, telling which card type is used. Like this one::
28 new entries which are not listed yet. If there isn't one for your
52 (``BT848_GPIO_OUT_EN``), it says which pins are actively driven by the
58 which does the sound routing. But every board is a little different.
63 As mentioned above, there is a array which holds the required
74 gpiomask specifies which pins are used to control the audio mux chip.
80 (i.e. which pins must be high/low for tuner/mute/...). This will be
92 You can have a look at the board to see which of the gpio pins are
[all …]
|
| /Documentation/networking/ |
| D | sysfs-tagging.rst | 26 and KOBJ_NS_TYPES, and ns will point to the namespace to which it
42 - call kobj_ns_type_register() with its ``kobj_ns_type_operations`` which has
44 - current_ns() which returns current's namespace
45 - netlink_ns() which returns a socket's namespace
46 - initial_ns() which returns the initial namespace
|
| /Documentation/filesystems/nfs/ |
| D | knfsd-stats.rst | 8 which the kernel NFS server makes available to userspace. These
10 which is described separately below.
28 The first line is a comment which describes the fields present in
38 The id number of the NFS thread pool to which this line applies.
45 which contains all the nfsd threads and all the CPUs in the system,
55 effects (such as Large Receive Offload) which can combine packets
57 of NFS calls received (which statistic is available elsewhere).
74 pool for the NFS workload (the workload is thread-limited), in which
83 network-facing NFS work is being handled quickly, which is a good
98 - Currently the rate at which the counter is incremented is quite
|
| /Documentation/mm/ |
| D | z3fold.rst | 7 It is a zbud derivative which allows for higher compression
19 up to 3 pages unlike zbud which can store at most 2. Therefore the
24 handle which encodes actual location of the allocated object.
28 which makes it a better fit for small and response-critical systems.
|
| /Documentation/ABI/obsolete/ |
| D | sysfs-driver-hid-roccat-savu | 4 Description: The mouse can store 5 profiles which can be switched by the
11 Which profile to write is determined by the profile number
14 which profile to read.
20 Description: When written, this file lets one select which data from which
28 Description: The mouse can store 5 profiles which can be switched by the
35 Which profile to write is determined by the profile number
56 which profile and key to read.
62 Description: The mouse can store 5 profiles which can be switched by the
|
| /Documentation/devicetree/bindings/clock/ |
| D | stericsson,u8500-clks.yaml | 39 management unit) clocks. The cell indicates which PRCMU clock in the
52 which PRCC block the consumer wants to use, possible values are 1, 2, 3,
53 5, 6. The second cell indicates which clock inside the PRCC block it
65 and clock controller) kernel clocks. The first cell indicates which PRCC
67 second cell indicates which clock inside the PRCC block it wants, possible
80 which PRCC block the consumer wants to use, possible values are 1, 2, 3
81 5 and 6. The second cell indicates which reset line inside the PRCC block
121 The first cell indicates which output clock we are using,
123 The second cell indicates which clock we want to use as source,
|
| /Documentation/i2c/ |
| D | instantiating-devices.rst | 6 level. Instead, the software must know which devices are connected on each
16 for many embedded systems. On such systems, each I2C bus has a number which
18 which live on this bus.
56 additional properties which might be needed to set up the device, please refer
64 which is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
73 struct i2c_board_info which is registered by calling
135 The above code instantiates 1 I2C device on the I2C bus which is on the
139 present or not (for example for an optional feature which is not present
167 The above code instantiates up to 1 I2C device on the I2C bus which is on
172 The driver which instantiated the I2C device is responsible for destroying
[all …]
|