Searched full:code (Results 1 – 25 of 1136) sorted by relevance
12345678910>>...46
| /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 | 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 | 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 | 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'
63 reviewers. If you believe that the reviewer has misunderstood your code,
[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
107 .. code-block:: c
116 .. code-block:: c
132 .. code-block:: c
149 .. code-block:: c
157 .. code-block:: c
177 .. code-block:: c
184 .. code-block:: none
[all …]
|
| D | clang-format.rst | 6 ``clang-format`` is a tool to format C/C++/... code according to
12 - Quickly reformat a block of code to the kernel style. Specially useful
13 when moving code around and aligning/sorting. See clangformatreformat_.
33 LLVM/clang binaries or build the source code from:
50 folders or individual files for code style mistakes, typos or improvements.
86 Reformatting blocks of code
90 blocks (selections) of code with a single keystroke. This is specially
91 useful when moving code around, for complex code that is deeply intended,
104 For Atom, Eclipse, Sublime Text, Visual Studio Code, XCode and other
117 in kernel code. They are easy to remember, so if you use the tool
[all …]
|
| D | volatile-considered-harmful.rst | 9 sometimes tempted to use it in kernel code when shared data structures are
12 kernel code is almost never correct; this document describes why.
25 almost certainly a bug in the code somewhere. In properly-written kernel
26 code, volatile can only serve to slow things down.
28 Consider a typical block of kernel code::
35 If all the code follows the locking rules, the value of shared_data cannot
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
98 For most code, none of the above justifications for volatile apply. As a
100 additional scrutiny to the code. Developers who are tempted to use
|
| /Documentation/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 …]
|
| D | kernel_user_helpers.rst | 5 These are segment of kernel provided user code reachable from user space
9 code to be executed directly in user mode for best efficiency but which is
11 In fact this code might even differ from one CPU to another depending on
13 words, the kernel reserves the right to change this code as needed without
19 constants that allows for efficient branching to those code segments. And
20 since those code segments only use a few cycles before returning to user
21 code, the overhead of a VDSO indirect far call would add a measurable
25 inline (either in the code emitted directly by the compiler, or part of
31 of not using these kernel helpers if your compiled code is not going to
134 r0 = success code (zero or non-zero)
[all …]
|
| D | mem_alignment.rst | 6 kernel code lately. Therefore the alignment fixup is now unconditionally
20 trap to SIGBUS any code performing unaligned access (good for debugging bad
21 code), or even fixup the access by software like for kernel code. The later
23 floating point emulation that works about the same way). Fix your code
39 fault code.
60 operation for user space code.
|
| /Documentation/scsi/ |
| D | arcmsr_spec.txt | 6 ** 1. Message 0 --> InitThread message and return code
19 ** offset 0xa00 : for inbound message code message_rwbuffer
21 ** offset 0xa00 : for outbound message code message_rwbuffer
52 ** 1 : Error, error code in AdapStatus/DevStatus/SenseData
64 ** 8. Message1 Out - Diag Status Code (????)
65 ** 9. Message0 message code :
68 ** ->offset 0xa00 :for outbound message code message_rwbuffer
82 ** ->offset 0xa00 :for inbound message code message_rwbuffer
94 ** ->offset 0xa00 : for inbound message code message_rwbuffer
113 ** command code, data and checksum byte
[all …]
|
| /Documentation/virt/kvm/ |
| D | s390-diag.txt | 28 the function code, and bits 0-47 are ignored.
35 DIAGNOSE function code 'X'500' - KVM virtio functions
38 If the function code specifies 0x500, various virtio-related functions
41 General register 1 contains the virtio subfunction code. Supported
46 the function's return code, which is either a return code or a subcode
77 DIAGNOSE function code 'X'501 - KVM breakpoint
80 If the function code specifies 0x501, breakpoint functions may be performed.
81 This function code is handled by userspace.
83 This diagnose function code has no subfunctions and uses no parameters.
|
| /Documentation/translations/zh_CN/process/ |
| D | coding-style.rst | 50 .. code-block:: c
71 .. code-block:: c
105 .. code-block:: c
113 .. code-block:: c
128 .. code-block:: c
142 .. code-block:: c
150 .. code-block:: c
168 .. code-block:: c
175 .. code-block:: c
184 .. code-block:: c
[all …]
|
| /Documentation/crypto/ |
| D | descore-readme.txt | 38 To more rapidly understand the code in this package, inspect desSmallFips.i
46 performance comparison to other available des code which i could
49 this code (byte-order independent):
61 used as drop-in replacements with mit's code or any of the mit-
94 (code from eay@psych.psy.uq.oz.au via comp.sources.misc)
99 performance. his code takes 26 sparc instructions to compute one
102 to use only 128k. his tables and code are machine independent.
103 (code from glad@daimi.aau.dk via alt.sources or comp.sources.misc)
109 he seems to have included a lot of special case code
112 (code obtained from chalmers.se:pub/des)
[all …]
|
| /Documentation/media/dvb-drivers/ |
| 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/block/ |
| D | biovecs.rst | 11 More specifically, old code that needed to partially complete a bio would
24 normal code doesn't have to deal with bi_bvec_done.
26 * Driver code should no longer refer to biovecs directly; we now have
32 instead of an integer (that corresponded to bi_idx); for a lot of code the
41 a pointer to a biovec, not a bio; this is used by the bio integrity code.
52 wouldn't necessarily be the same size, the old code was tricky convoluted -
56 The new code is much more straightforward - have a look. This sort of
59 simplifies a lot of code.
61 * Before, any code that might need to use the biovec after the bio had been
82 occasionally in stacking block drivers and various code (e.g. md and
[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 …]
|
| D | highres.rst | 48 code out of the architecture-specific areas into a generic management
52 decision. The low level code provides hardware setup and readout routines and
53 initializes data structures, which are used by the generic time keeping code to
55 related functionality is moved into the generic code. The GTOD base patch got
77 dependent code. This results in duplicated code across all architectures and
87 to minimize the clock event related architecture dependent code to the pure
89 clock event devices. It also minimizes the duplicated code across the
94 code or at module insertion time. Each clock event device fills a data
115 from the hardware level handler. This removes a lot of duplicated code from the
118 to the core code.
[all …]
|
| /Documentation/x86/ |
| D | exception-tables.rst | 40 contains a reason code for the exception.
59 to executable code. This code is hidden inside the user access macros.
62 the code generated by the preprocessor and the compiler. I selected
65 The original code in sysrq.c line 587::
132 see what code gcc generates::
172 > CONTENTS, ALLOC, LOAD, READONLY, CODE
174 > CONTENTS, ALLOC, LOAD, READONLY, CODE
189 file. But first we want to find out what happened to our code in the
237 told the assembler to move the following code to the specified
252 the original assembly code: > 1: movb (%ebx),%dl
[all …]
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | nvidia,tegra20-emc.txt | 9 - nvidia,use-ram-code : If present, the sub-nodes will be addressed
12 irrespective of ram-code configuration.
30 Embedded Memory Controller ram-code table
32 If the emc node has the nvidia,use-ram-code property present, then the
34 apply for which ram-code settings.
36 If the emc node lacks the nvidia,use-ram-code property, this level is omitted
42 - nvidia,ram-code : the binary representation of the ram-code board strappings
64 on a 2-pin "ram code" bootstrap setting on the board. The values of
|
| /Documentation/hwmon/ |
| D | pmbus-core.rst | 35 split into core, generic, and device specific code. The core code (in
36 pmbus_core.c) provides generic functionality. The generic code (in pmbus.c)
37 provides support for generic PMBus devices. Device specific code is responsible
40 to PCI code, where generic code is augmented as needed with quirks for all kinds
46 For generic PMBus devices, code in pmbus.c attempts to auto-detect all supported
65 The API between core and device specific PMBus code is defined in
85 to be implemented in device specific code.
97 Virtual commands have to be handled in device specific driver code. Chip driver
98 code returns non-negative values if a virtual command is supported, or a
99 negative error code if not. The chip driver may return -ENODATA or any other
[all …]
|
| /Documentation/ |
| D | irqflags-tracing.txt | 14 code. Otherwise only CONFIG_PROVE_MUTEX_LOCKING and
20 category, because lots of lowlevel assembly code deal with irq-flags
25 code-organizational changes first:
32 - in lowlevel entry code add (build-conditional) calls to the
38 complaint, try to figure out the assembly code we did not cover yet,
50 changes break other code by modifying conditions or registers that
|
| /Documentation/parisc/ |
| D | debugging.rst | 12 A lot of the assembly code currently runs in real mode, which means
22 When real-mode code tries to access non-existent memory, you'll get
27 code tried to access.
31 get translated to a physical address before real-mode code tried to
38 Certain, very critical code has to clear the Q bit in the PSW. What
|
| /Documentation/driver-api/mtd/ |
| D | nand_ecc.rst | 2 NAND Error-correction Code
9 I felt there was room for optimisation. I bashed the code for a few hours
10 performing tricks like table lookup removing superfluous code etc.
26 This is done by means of a Hamming code. I'll try to explain it in
174 Therefore without implementing this it was clear that the code above was
212 void ecc1(const unsigned char *buf, unsigned char *code)
240 code[0] =
249 code[1] =
258 code[2] =
265 code[0] = ~code[0];
[all …]
|
12345678910>>...46