Lines Matching full:of
7 process, the proof of any kernel development project is in the resulting
9 (or not) into the mainline tree. So it is the quality of this code which
10 will determine the ultimate success of the project.
13 number of ways in which kernel developers can go wrong. Then the focus
25 :ref:`Documentation/process/coding-style.rst <codingstyle>`. For much of
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
31 The first of these is to believe that the kernel coding standards do not
32 matter and are not enforced. The truth of the matter is that adding new
36 requires some uniformity of code to make it possible for developers to
37 quickly understand any part of it. So there is no longer room for
43 giving up a degree of control in a number of ways - including control over
47 urgently in need of coding style fixes. Developers may start to generate
48 reformatting patches as a way of gaining familiarity with the process, or
49 as a way of getting their name into the kernel changelogs - or both. But
51 they tend to get a chilly reception. So this type of patch is best
52 avoided. It is natural to fix the style of a piece of code while working
62 these rules, to quickly re-format parts of your code automatically,
77 Computer Science professors teach students to make extensive use of
78 abstraction layers in the name of flexibility and information hiding.
79 Certainly the kernel makes extensive use of abstraction; no project
80 involving several million lines of code could do otherwise and survive.
97 of a driver to be used with multiple operating systems - are especially
101 On the other hand, if you find yourself copying significant amounts of code
103 make sense to pull out some of that code into a separate library or to
112 programmers, who see it as a way to efficiently encode a great deal of
114 use of it results in code which is much harder for others to read and
116 is almost always a sign of code which needs some cleanup work.
127 C preprocessor macros present a number of hazards, including possible
128 multiple evaluation of expressions with side effects and no type safety.
138 Inline functions present a hazard of their own, though. Programmers can
139 become enamored of the perceived efficiency inherent in avoiding a function
142 at each call site, they end up bloating the size of the compiled kernel.
145 small and relatively rare. The cost of a function call, after all, is not
146 that high; the creation of large numbers of inline functions is a classic
147 example of premature optimization.
156 placement of "inline" keywords may not just be excessive; it could also be
167 stack offered the promise of fixing that situation. Yet, this code did not
171 This code showed a number of signs of having been developed behind
181 raise the level of concurrency within the kernel. The days when kernel
189 enough to pick the right tool for the job. Code which shows a lack of
198 for existing users. This kind of change is called a "regression," and
219 An especially unwelcome type of regression is any sort of change to the
221 be supported indefinitely. This fact makes the creation of user-space
224 reason, a great deal of thought, clear documentation, and wide review for
231 For now, at least, the writing of error-free code remains an ideal that few
232 of us can reach. What we can hope to do, though, is to catch and fix as
233 many of those errors as possible before our code goes into the mainline
235 array of tools which can catch a wide variety of obscure problems in an
241 Contemporary versions of gcc can detect (and warn about) a large number of
252 features; most of these are found in the "kernel hacking" submenu. Several
253 of these options should be turned on for any kernel used for development or
258 warnings from other parts of the kernel.
260 - DEBUG_OBJECTS will add code to track the lifetime of various objects
261 created by the kernel and warn when things are done out of order. If
263 of its own, consider adding support for the object debugging
266 - DEBUG_SLAB can find a variety of memory allocation and use errors; it
270 number of common locking errors.
272 There are quite a few other debugging options, some of which will be
273 discussed below. Some of them have a significant performance impact and
274 should not be used all of the time. But some time spent learning the
277 One of the heavier debugging tools is the locking checker, or "lockdep."
278 This tool will track the acquisition and release of every lock (spinlock or
283 lockdep can find a number of scenarios in which the system could, on rare
284 occasion, deadlock. This kind of problem can be painful (for both
286 in an automated manner ahead of time. Code with any sort of non-trivial
291 status of any operation (such as a memory allocation) which can fail. The
292 fact of the matter, though, is that the resulting failure recovery paths
294 you could be much more confident of your code if all those error-handling
299 enabled, a configurable percentage of memory allocations will be made to
300 fail; these failures can be restricted to a specific range of code.
306 Other kinds of errors can be found with the "sparse" static analysis tool.
308 user-space and kernel-space addresses, mixture of big-endian and
309 small-endian quantities, the passing of integer values where a set of bit
316 variety of potential coding problems; it can also propose fixes for those
323 Other kinds of portability errors are best found by compiling your code for
326 step. A large set of cross compilers for x86 systems can be found at
339 of new code into the kernel, make life easier for other developers, and
340 will be helpful for your users. In many cases, the addition of
343 The first piece of documentation for any patch is its associated
345 of the solution, the people who worked on the patch, any relevant
348 worth applying; a surprising number of developers fail to provide that
352 /proc files - should include documentation of that interface which enables
354 Documentation/ABI/README for a description of how this documentation should
358 <kernelparameters>` describes all of the kernel's boot-time parameters.
365 Internal API information for many subsystems is documented by way of
367 in a number of ways by the "kernel-doc" script. If you are working within
372 beginning kernel developers. The format of these comments, along with some
376 Anybody who reads through a significant amount of existing kernel code will
383 Certain things should always be commented. Uses of memory barriers should
387 Non-obvious dependencies between separate bits of code should be pointed
403 There are, of course, some catches. API changes can be made, but they need
405 accompanied by a description of what the change is and why it is
406 necessary. This kind of change should also be broken out into a separate
410 generally charged with the task of fixing any code within the kernel tree
412 lead to literally hundreds or thousands of changes - many of which are
420 This will help you to be sure that you have found all in-tree uses of that
421 interface. It will also alert developers of out-of-tree code that there is
422 a change that they need to respond to. Supporting out-of-tree code is not
424 not have to make life harder for out-of-tree developers than it needs to