Lines Matching +full:in +full:- +full:kernel
6 While there is much to be said for a solid and community-oriented design
7 process, the proof of any kernel development project is in the resulting
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
19 ---------
24 The kernel has long had a standard coding style, described in
25 :ref:`Documentation/process/coding-style.rst <codingstyle>`. For much of
26 that time, the policies described in that file were taken as being, at most,
27 advisory. As a result, there is a substantial amount of code in the kernel
29 leads to two independent hazards for kernel developers.
31 The first of these is to believe that the kernel coding standards do not
33 code to the kernel is very difficult if that code is not coded according to
35 before they will even review it. A code base as large as the kernel
38 strangely-formatted code.
40 Occasionally, the kernel's coding style will run into conflict with an
41 employer's mandated style. In such cases, the kernel's style will have to
42 win before the code can be merged. Putting code into the kernel means
43 giving up a degree of control in a number of ways - including control over
46 The other trap is to assume that code which is already in the kernel is
47 urgently in need of coding style fixes. Developers may start to generate
49 as a way of getting their name into the kernel changelogs - or both. But
59 80-column limit, for example), just do it.
61 Note that you can also use the ``clang-format`` tool to help you with
62 these rules, to quickly re-format parts of your code automatically,
63 and to review full files in order to spot coding style mistakes,
66 See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
74 abstraction layers in the name of flexibility and information hiding.
75 Certainly the kernel makes extensive use of abstraction; no project
83 in case somebody eventually needs to use the extra flexibility that it
85 implements this extra argument has been broken in some subtle way which was
86 never noticed - because it has never been used. Or, when the need for
87 extra flexibility arises, it does not do so in a way which matches the
88 programmer's early expectation. Kernel developers will routinely submit
89 patches to remove unused arguments; they should, in general, not be added
90 in the first place.
92 Abstraction layers which hide access to hardware - often to allow the bulk
93 of a driver to be used with multiple operating systems - are especially
95 penalty; they do not belong in the Linux kernel.
98 from another kernel subsystem, it is time to ask whether it would, in fact,
100 implement that functionality at a higher level. There is no value in
101 replicating the same code throughout the kernel.
104 #ifdef and preprocessor use in general
110 use of it results in code which is much harder for others to read and
115 is used within the kernel. But there is little desire to see code which is
118 Conditionally-compiled code can be confined to functions which, if the code
135 become enamored of the perceived efficiency inherent in avoiding a function
138 at each call site, they end up bloating the size of the compiled kernel.
139 That, in turn, creates pressure on the processor's memory caches, which can
145 In general, kernel programmers ignore cache effects at their peril. The
146 classic time/space tradeoff taught in beginning data structures classes
147 often does not apply to contemporary hardware. Space *is* time, in that a
150 More recent compilers take an increasingly active role in deciding whether
159 In May, 2006, the "Devicescape" networking stack was, with great
160 fanfare, released under the GPL and made available for inclusion in the
161 mainline kernel. This donation was welcome news; support for wireless
162 networking in Linux was considered substandard at best, and the Devicescape
168 corporate doors. But one large problem in particular was that it was not
173 Once upon a time, Linux kernel code could be developed without thinking
175 however, this document is being written on a dual-core laptop. Even on
176 single-processor systems, work being done to improve responsiveness will
177 raise the level of concurrency within the kernel. The days when kernel
182 New code should be written with this requirement in mind; retrofitting
183 locking after the fact is a rather more difficult task. Kernel developers
195 regressions have become most unwelcome in the mainline kernel. With few
197 regression cannot be fixed in a timely manner. Far better to avoid the
198 regression in the first place.
203 breaks? The best answer to this question was expressed by Linus in July,
216 user-space ABI. Once an interface has been exported to user space, it must
217 be supported indefinitely. This fact makes the creation of user-space
218 interfaces particularly challenging: since they cannot be changed in
221 user-space interfaces is always required.
225 -------------------
227 For now, at least, the writing of error-free code remains an ideal that few
230 kernel. To that end, the kernel developers have put together an impressive
231 array of tools which can catch a wide variety of obscure problems in an
245 kernel with "make KCFLAGS=-W" to get the full set.
247 The kernel provides several configuration options which turn on debugging
248 features; most of these are found in the "kernel hacking" submenu. Several
249 of these options should be turned on for any kernel used for development or
250 testing purposes. In particular, you should turn on:
252 - FRAME_WARN to get warnings for stack frames larger than a given amount.
254 warnings from other parts of the kernel.
256 - DEBUG_OBJECTS will add code to track the lifetime of various objects
257 created by the kernel and warn when things are done out of order. If
262 - DEBUG_SLAB can find a variety of memory allocation and use errors; it
265 - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, and DEBUG_MUTEXES will find a
271 available options will likely be paid back many times over in short order.
275 mutex) in the system, the order in which locks are acquired relative to
277 ensure that locks are always acquired in the same order, that the same
278 interrupt assumptions apply in all situations, and so on. In other words,
279 lockdep can find a number of scenarios in which the system could, on rare
281 developers and users) in a deployed system; lockdep allows them to be found
282 in an automated manner ahead of time. Code with any sort of non-trivial
286 As a diligent kernel programmer, you will, beyond doubt, check the return
290 you could be much more confident of your code if all those error-handling
293 The kernel provides a fault injection framework which can do exactly that,
299 Documentation/fault-injection/fault-injection.rst for more information on
304 user-space and kernel-space addresses, mixture of big-endian and
305 small-endian quantities, the passing of integer values where a set of bit
307 be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your
313 problems. Quite a few "semantic patches" for the kernel have been packaged
316 :ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`
324 https://www.kernel.org/pub/tools/crosstool/
331 -------------
333 Documentation has often been more the exception than the rule with kernel
335 of new code into the kernel, make life easier for other developers, and
336 will be helpful for your users. In many cases, the addition of
347 Any code which adds a new user-space interface - including new sysfs or
348 /proc files - should include documentation of that interface which enables
349 user-space developers to know what they are working with. See
353 The file :ref:`Documentation/admin-guide/kernel-parameters.rst
354 <kernelparameters>` describes all of the kernel's boot-time parameters.
362 specially-formatted comments; these comments can be extracted and formatted
363 in a number of ways by the "kernel-doc" script. If you are working within
365 them, as appropriate, for externally-available functions. Even in areas
366 which have not been so documented, there is no harm in adding kerneldoc
368 beginning kernel developers. The format of these comments, along with some
370 :ref:`Documentation/doc-guide/ <doc_guide>`.
372 Anybody who reads through a significant amount of existing kernel code will
374 the expectations for new code are higher than they were in the past;
376 for verbosely-commented code. The code should, itself, be readable, with
382 Major data structures need comprehensive documentation in general.
383 Non-obvious dependencies between separate bits of code should be pointed
389 --------------------
391 The binary interface provided by the kernel to user space cannot be broken
392 except under the most severe circumstances. The kernel's internal
394 the need arises. If you find yourself having to work around a kernel API,
396 needs, that may be a sign that the API needs to change. As a kernel
406 generally charged with the task of fixing any code within the kernel tree
407 which is broken by the change. For a widely-used function, this duty can
408 lead to literally hundreds or thousands of changes - many of which are
412 wide-ranging API changes.
416 This will help you to be sure that you have found all in-tree uses of that
417 interface. It will also alert developers of out-of-tree code that there is
418 a change that they need to respond to. Supporting out-of-tree code is not
419 something that kernel developers need to be worried about, but we also do
420 not have to make life harder for out-of-tree developers than it needs to