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,
73 Computer Science professors teach students to make extensive use of
74 abstraction layers in the name of flexibility and information hiding.
75 Certainly the kernel makes extensive use of abstraction; no project
76 involving several million lines of code could do otherwise and survive.
93 of a driver to be used with multiple operating systems - are especially
97 On the other hand, if you find yourself copying significant amounts of code
99 make sense to pull out some of that code into a separate library or to
108 programmers, who see it as a way to efficiently encode a great deal of
110 use of it results in code which is much harder for others to read and
112 is almost always a sign of code which needs some cleanup work.
123 C preprocessor macros present a number of hazards, including possible
124 multiple evaluation of expressions with side effects and no type safety.
134 Inline functions present a hazard of their own, though. Programmers can
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.
141 small and relatively rare. The cost of a function call, after all, is not
142 that high; the creation of large numbers of inline functions is a classic
143 example of premature optimization.
152 placement of "inline" keywords may not just be excessive; it could also be
163 stack offered the promise of fixing that situation. Yet, this code did not
167 This code showed a number of signs of having been developed behind
177 raise the level of concurrency within the kernel. The days when kernel
185 enough to pick the right tool for the job. Code which shows a lack of
194 for existing users. This kind of change is called a "regression," and
215 An especially unwelcome type of regression is any sort of change to the
217 be supported indefinitely. This fact makes the creation of user-space
220 reason, a great deal of thought, clear documentation, and wide review for
227 For now, at least, the writing of error-free code remains an ideal that few
228 of us can reach. What we can hope to do, though, is to catch and fix as
229 many of those errors as possible before our code goes into the mainline
231 array of tools which can catch a wide variety of obscure problems in an
237 Contemporary versions of gcc can detect (and warn about) a large number of
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
253 extra set of warnings for problems like the use of deprecated interfaces
256 warnings from other parts of the kernel.
258 - DEBUG_OBJECTS will add code to track the lifetime of various objects
259 created by the kernel and warn when things are done out of order. If
261 of its own, consider adding support for the object debugging
264 - DEBUG_SLAB can find a variety of memory allocation and use errors; it
268 number of common locking errors.
270 There are quite a few other debugging options, some of which will be
271 discussed below. Some of them have a significant performance impact and
272 should not be used all of the time. But some time spent learning the
275 One of the heavier debugging tools is the locking checker, or "lockdep."
276 This tool will track the acquisition and release of every lock (spinlock or
281 lockdep can find a number of scenarios in which the system could, on rare
282 occasion, deadlock. This kind of problem can be painful (for both
284 in an automated manner ahead of time. Code with any sort of non-trivial
289 status of any operation (such as a memory allocation) which can fail. The
290 fact of the matter, though, is that the resulting failure recovery paths
292 you could be much more confident of your code if all those error-handling
297 enabled, a configurable percentage of memory allocations will be made to
298 fail; these failures can be restricted to a specific range of code.
304 Other kinds of errors can be found with the "sparse" static analysis tool.
306 user-space and kernel-space addresses, mixture of big-endian and
307 small-endian quantities, the passing of integer values where a set of bit
314 variety of potential coding problems; it can also propose fixes for those
321 Other kinds of portability errors are best found by compiling your code for
324 step. A large set of cross compilers for x86 systems can be found at
337 of new code into the kernel, make life easier for other developers, and
338 will be helpful for your users. In many cases, the addition of
341 The first piece of documentation for any patch is its associated
343 of the solution, the people who worked on the patch, any relevant
346 worth applying; a surprising number of developers fail to provide that
350 /proc files - should include documentation of that interface which enables
352 Documentation/ABI/README for a description of how this documentation should
356 <kernelparameters>` describes all of the kernel's boot-time parameters.
363 Internal API information for many subsystems is documented by way of
365 in a number of ways by the "kernel-doc" script. If you are working within
370 beginning kernel developers. The format of these comments, along with some
374 Anybody who reads through a significant amount of existing kernel code will
381 Certain things should always be commented. Uses of memory barriers should
385 Non-obvious dependencies between separate bits of code should be pointed
401 There are, of course, some catches. API changes can be made, but they need
403 accompanied by a description of what the change is and why it is
404 necessary. This kind of change should also be broken out into a separate
408 generally charged with the task of fixing any code within the kernel tree
410 lead to literally hundreds or thousands of changes - many of which are
418 This will help you to be sure that you have found all in-tree uses of that
419 interface. It will also alert developers of out-of-tree code that there is
420 a change that they need to respond to. Supporting out-of-tree code is not
422 not have to make life harder for out-of-tree developers than it needs to