Searched full:code (Results 1 – 25 of 1488) sorted by relevance
12345678910>>...60
| /Documentation/process/ |
| D | 1.Intro.rst | 11 encounter there. There are a great many reasons why kernel code should be
14 influence the direction of kernel development. Code contributed to the
53 The Linux kernel, at over 8 million lines of code and well over 1000
86 thousands of lines of code are being changed every day. So it is not
117 The importance of getting code into the mainline
121 learning how to work with the kernel community and get their code into the
124 contributing code can look like an avoidable expense; it seems easier to
125 just keep the code separate and support users directly. The truth of the
126 matter is that keeping code separate ("out of tree") is a false economy.
128 As a way of illustrating the costs of out-of-tree code, here are a few
[all …]
|
| D | code-of-conduct-interpretation.rst | 3 Linux Kernel Contributor Covenant Code of Conduct Interpretation
27 The Code of Conduct uses the term "maintainers" numerous times. In the
35 The Code of Conduct mentions rights and responsibilities for
44 responsibility is upon all of us, and ultimately the Code of Conduct
59 of problems. Enforcement of the code of conduct will only be a last
78 Code of Conduct.
83 the Code of Conduct. The kernel community is aware of that and provides
93 sent to those mailing lists are considered covered by the Code of
97 or bug tracking tools should follow the guidelines of the Code of
100 performed using a kernel.org email account must follow the Code of
[all …]
|
| D | 4.Coding.rst | 3 Getting the code right
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
27 advisory. As a result, there is a substantial amount of code in the kernel
28 which does not meet the coding style guidelines. The presence of that code
33 code to the kernel is very difficult if that code is not coded according to
34 the standard; many developers will request that the code be reformatted
35 before they will even review it. A code base as large as the kernel
36 requires some uniformity of code to make it possible for developers to
38 strangely-formatted code.
[all …]
|
| D | 6.Followthrough.rst | 16 code. You, as the author of that code, will be expected to work with the
17 kernel community to ensure that your code is up to the kernel's quality
26 developers as they review the code. Working with reviewers can be, for
34 like to maintain a kernel with this code in it five or ten years later?
39 - Code review is hard work, and it is a relatively thankless occupation;
40 people remember who wrote kernel code, but there is little lasting fame
44 impulse to respond in kind. Code review is about the code, not about
45 the people, and code reviewers are not attacking you personally.
47 - Similarly, code reviewers are not trying to promote their employers'
55 and requests to factor out some of your code to shared parts of
[all …]
|
| D | code-of-conduct.rst | 3 Contributor Covenant Code of Conduct
49 comments, commits, code, wiki edits, issues, and other contributions that are
50 not aligned to this Code of Conduct, or to ban temporarily or permanently any
57 This Code of Conduct applies both within project spaces and in public spaces
68 reported by contacting the Code of Conduct Committee at
71 to the circumstances. The Code of Conduct Committee is obligated to
79 This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
80 available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
| D | coding-style.rst | 32 the code move too far to the right, and makes it hard to read on a
45 .. code-block:: c
67 .. code-block:: c
74 .. code-block:: c
81 .. code-block:: c
129 .. code-block:: c
138 .. code-block:: c
154 .. code-block:: c
171 .. code-block:: c
179 .. code-block:: c
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-soc | 31 code. The format is "jep106:XXYY" where XX is identity code and
32 YY is continuation code.
34 This manufacturer’s identification code is defined by one
41 The specified mechanism is that an identity code of 0x7F
42 represents the "continuation code" and implies the presence
43 of an additional identity code field, and this mechanism
45 by the manufacturer's identity code.
47 For example, ARM has identity code 0x7F 0x7F 0x7F 0x7F 0x3B,
48 which is code 0x3B on the fifth 'page'. This is shortened
49 as JEP106 identity code of 0x3B and a continuation code of
[all …]
|
| /Documentation/core-api/ |
| D | entry.rst | 18 Non-instrumentable code - noinstr
22 for entry code before RCU starts watching and exit code after RCU stops
24 which means that (for example) a breakpoint in the breakpoint entry code would
27 Such code must be marked with the 'noinstr' attribute, placing that code into a
31 instrumentable ranges of code:
33 .. code-block:: c
41 handle_context(); // <-- instrumentable code
55 All non-instrumentable entry/exit code sections before and after the RCU
61 Syscall-entry code starts in assembly code and calls out into low-level C code
63 low-level C code must not be instrumented. A typical syscall handling function
[all …]
|
| D | floating-point.rst | 6 Kernel code is normally prohibited from using floating-point (FP) registers or
11 However, occasionally drivers or library functions may need to include FP code.
12 This is supported by isolating the functions containing FP code to a separate
17 The reason for this isolation is to prevent the compiler from generating code
22 Usability of floating-point code within the kernel is architecture-specific.
34 Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT``
35 is enabled. For C code, such code must be placed in a separate file, and that
50 Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``.
56 from files implementing FP code (those with their compilation flags adjusted as
61 This function reports if floating-point code can be used on this CPU or
|
| /Documentation/arch/arm/ |
| D | kernel_mode_neon.rst | 8 code
9 * Isolate your NEON code in a separate compilation unit, and compile it with
12 NEON code
13 * Don't sleep in your NEON code, and be aware that it will be executed with
20 code that runs in kernel mode. However, for performance reasons, the NEON/VFP
23 required. Furthermore, special care is required for code that may sleep [i.e.,
56 * NEON/VFP code is not allowed in interrupt context;
57 * NEON/VFP code is not allowed to sleep;
58 * NEON/VFP code is executed with preemption disabled.
61 kernel_neon_end() and kernel_neon_begin() in places in your code where none of
[all …]
|
| /Documentation/rust/ |
| D | coding-guidelines.rst | 6 This document describes how to write Rust code in the kernel.
12 The code should be formatted using ``rustfmt``. In this way, a person
39 even work with broken code.
45 "Normal" comments (i.e. ``//``, rather than code documentation which starts
51 .. code-block:: rust
60 .. code-block:: rust
73 .. code-block:: rust
89 before every ``unsafe`` block, and they explain why the code inside the block is
92 .. code-block:: rust
98 in code documentation. ``# Safety`` sections specify the contract that callers
[all …]
|
| /Documentation/filesystems/bcachefs/ |
| D | errorcodes.rst | 11 direct uses of standard error codes you see in the source code are simply old
12 code that has yet to be converted - feel free to clean it up!
14 Private error codes may subtype another error code, this allows for grouping of
16 errors), as well as specifying which standard error code should be returned at
20 code; this also emits a trace event so that the original error code be
23 Do not reuse error codes! Generally speaking, a private error code should only
|
| D | CodingStyle.rst | 14 The code that you are afraid to touch is the code most in need of refactoring.
20 Good code is readable code, where the structure is simple and leaves nowhere
23 Assertions are one of our most important tools for writing reliable code. If in
55 can still incorporate that kind of thinking into our code and document the
58 code statically typed.
63 Good code is code where you can poke around and see what it's doing -
121 Spend time doing support and helpdesk stuff. Don't just write code - code isn't
132 idea until you start writing code.
135 Nobody writes all perfect code that all gets shipped, and you'll be much more
141 existing code. Sometimes these can be the best projects, because they can lead
[all …]
|
| /Documentation/bpf/ |
| D | map_devmap.rst | 25 The setup and packet enqueue/send code is shared between the two types of
34 .. code-block:: c
42 The lower two bits of *flags* are used as the return code if the map lookup
64 .. code-block:: c
80 .. code-block:: c
89 .. code-block:: c
117 .. code-block:: c
127 .. code-block:: c
142 The following code snippet shows how to declare a ``BPF_MAP_TYPE_DEVMAP``
145 .. code-block:: c
[all …]
|
| /Documentation/maintainer/ |
| D | feature-and-driver-maintainers.rst | 13 responsibilities of maintainers of a small(ish) section of the code.
23 and popularity of the code base. Small features and drivers should
58 When there are multiple maintainers for a piece of code an ``Acked-by``
70 Occasionally core code needs to be changed to improve the maintainability
72 help guide and test changes to their code to fit the new infrastructure.
77 Maintainers must ensure severe problems in their code reported to them
89 Discussions about user reported issues, and development of new code
107 Most natural and common choice of a maintainer is the author of the code.
108 The author is intimately familiar with the code, so it is the best person
113 it is a list of those who will actively help with the code.
[all …]
|
| /Documentation/translations/zh_CN/process/ |
| D | coding-style.rst | 52 .. code-block:: c
73 .. code-block:: c
80 .. code-block:: c
87 .. code-block:: c
128 .. code-block:: c
136 .. code-block:: c
151 .. code-block:: c
165 .. code-block:: c
173 .. code-block:: c
191 .. code-block:: c
[all …]
|
| /Documentation/translations/zh_TW/process/ |
| D | coding-style.rst | 55 .. code-block:: c
76 .. code-block:: c
83 .. code-block:: c
90 .. code-block:: c
131 .. code-block:: c
139 .. code-block:: c
154 .. code-block:: c
168 .. code-block:: c
176 .. code-block:: c
194 .. code-block:: c
[all …]
|
| /Documentation/livepatch/ |
| D | reliable-stacktrace.rst | 18 Existing stacktrace code may not always give an accurate picture of all
36 return code is zero to indicate that the trace is reliable.
38 * The return code is non-zero to indicate that the trace is not reliable.
48 code, and should not get stuck in an infinite loop or access memory in
55 To ensure that kernel code can be correctly unwound in all cases,
56 architectures may need to verify that code has been compiled in a manner
84 * Dynamically generated code (e.g. eBPF) or foreign code (e.g. EFI runtime
98 4.2 Identifying unwindable code
101 Unwinding typically relies on code following specific conventions (e.g.
102 manipulating a frame pointer), but there can be code which may not follow these
[all …]
|
| /Documentation/virt/kvm/s390/ |
| D | s390-diag.rst | 31 the function code, and bits 0-47 are ignored.
38 DIAGNOSE function code 'X'500' - KVM virtio functions
41 If the function code specifies 0x500, various virtio-related functions
44 General register 1 contains the virtio subfunction code. Supported
49 the function's return code, which is either a return code or a subcode
80 DIAGNOSE function code 'X'501 - KVM breakpoint
83 If the function code specifies 0x501, breakpoint functions may be performed.
84 This function code is handled by userspace.
86 This diagnose function code has no subfunctions and uses no parameters.
89 DIAGNOSE function code 'X'9C - Voluntary Time Slice Yield
[all …]
|
| /Documentation/timers/ |
| D | hrtimers.rst | 12 conclusion that the timer wheel code is fundamentally not suitable for
20 mess. The timers.c code is very "tightly coded" around jiffies and
25 code is very good and tight code, there's zero problems with it in its
34 degrading other portions of the timers.c code in an unacceptable way.
43 - the timer wheel code is most optimal for use cases which can be
88 - simplification of existing, timing related kernel code
96 a separate list is used to give the expiry code fast access to the
109 time-changing code had to fix them up one by one, and all of them had to
112 scaling code from the posix-timer implementation - the clock can simply
117 existing timer wheel code, as it is mature and well suited. Sharing code
[all …]
|
| /Documentation/dev-tools/kunit/ |
| D | running_tips.rst | 15 .. code-block:: bash
33 .. code-block:: bash
40 .. code-block:: bash
62 .. code-block:: bash
69 .. code-block:: bash
95 .. code-block:: bash
100 Generating code coverage reports under UML
113 .. code-block:: none
123 .. code-block:: bash
137 .. code-block:: bash
[all …]
|
| /Documentation/admin-guide/media/ |
| D | lmedm04.rst | 19 .. code-block:: none
32 .. code-block:: none
49 .. code-block:: none
64 .. code-block:: none
76 .. code-block:: none
85 .. code-block:: none
95 .. code-block:: none
102 .. code-block:: none
|
| /Documentation/userspace-api/netlink/ |
| D | intro-specs.rst | 14 developing Netlink related code. The tool is implemented in Python
51 code from ``cli.py``.
53 Generating kernel code
58 way to generate / update auto-generated code.
60 By default code is re-generated only if spec is newer than the source,
78 The code generation itself is performed by ``tools/net/ynl/ynl-gen-c.py``
86 (based on libmnl) which integrates with code generated by
92 The YNL library consists of two parts - the generic code (functions
93 prefix by ``ynl_``) and per-family auto-generated code (prefixed
97 struct (family structs are exported by the auto-generated code).
[all …]
|
| /Documentation/translations/zh_CN/rust/ |
| D | coding-guidelines.rst | 48 .. code-block:: rust
56 .. code-block:: rust
65 .. code-block:: rust
83 .. code-block:: rust
106 .. code-block:: rust
162 .. code-block:: rust
168 .. code-block:: rust
187 .. code-block:: c
194 .. code-block:: rust
|
| /Documentation/virt/hyperv/ |
| D | overview.rst | 5 The Linux kernel contains a variety of code for running as a fully
59 only from the code.
91 Kbyte pages, Linux code must be careful to communicate with Hyper-V
93 are used in code that communicates with Hyper-V so that it works
116 guest VMs, so Linux code must individually revoke all sharing before
154 supported by Hyper-V, and Linux code does not use endian-ness macros
166 number and is for display purposes only. Linux code does not
170 and the guest code tests these flags.
175 is checked in a few places in the code to determine if specific
184 Code Packaging
[all …]
|
12345678910>>...60