Lines Matching refs:of
4 process, the proof of any kernel development project is in the resulting
6 (or not) into the mainline tree. So it is the quality of this code which
7 will determine the ultimate success of the project.
10 number of ways in which kernel developers can go wrong. Then the focus
20 Documentation/CodingStyle. For much of that time, the policies described
22 a substantial amount of code in the kernel which does not meet the coding
23 style guidelines. The presence of that code leads to two independent
26 The first of these is to believe that the kernel coding standards do not
27 matter and are not enforced. The truth of the matter is that adding new
31 requires some uniformity of code to make it possible for developers to
32 quickly understand any part of it. So there is no longer room for
38 giving up a degree of control in a number of ways - including control over
42 urgently in need of coding style fixes. Developers may start to generate
43 reformatting patches as a way of gaining familiarity with the process, or
44 as a way of getting their name into the kernel changelogs - or both. But
46 they tend to get a chilly reception. So this type of patch is best
47 avoided. It is natural to fix the style of a piece of code while working
59 Computer Science professors teach students to make extensive use of
60 abstraction layers in the name of flexibility and information hiding.
61 Certainly the kernel makes extensive use of abstraction; no project
62 involving several million lines of code could do otherwise and survive.
79 of a driver to be used with multiple operating systems - are especially
83 On the other hand, if you find yourself copying significant amounts of code
85 make sense to pull out some of that code into a separate library or to
93 programmers, who see it as a way to efficiently encode a great deal of
95 use of it results in code which is much harder for others to read and
97 is almost always a sign of code which needs some cleanup work.
108 C preprocessor macros present a number of hazards, including possible
109 multiple evaluation of expressions with side effects and no type safety.
118 Inline functions present a hazard of their own, though. Programmers can
119 become enamored of the perceived efficiency inherent in avoiding a function
122 at each call site, they end up bloating the size of the compiled kernel.
125 small and relatively rare. The cost of a function call, after all, is not
126 that high; the creation of large numbers of inline functions is a classic
127 example of premature optimization.
136 placement of "inline" keywords may not just be excessive; it could also be
146 stack offered the promise of fixing that situation. Yet, this code did not
150 This code showed a number of signs of having been developed behind
160 raise the level of concurrency within the kernel. The days when kernel
168 enough to pick the right tool for the job. Code which shows a lack of
176 for existing users. This kind of change is called a "regression," and
195 An especially unwelcome type of regression is any sort of change to the
197 be supported indefinitely. This fact makes the creation of user-space
200 reason, a great deal of thought, clear documentation, and wide review for
207 For now, at least, the writing of error-free code remains an ideal that few
208 of us can reach. What we can hope to do, though, is to catch and fix as
209 many of those errors as possible before our code goes into the mainline
211 array of tools which can catch a wide variety of obscure problems in an
217 Contemporary versions of gcc can detect (and warn about) a large number of
228 features; most of these are found in the "kernel hacking" submenu. Several
229 of these options should be turned on for any kernel used for development or
233 extra set of warnings for problems like the use of deprecated interfaces
236 warnings from other parts of the kernel.
238 - DEBUG_OBJECTS will add code to track the lifetime of various objects
239 created by the kernel and warn when things are done out of order. If
241 of its own, consider adding support for the object debugging
244 - DEBUG_SLAB can find a variety of memory allocation and use errors; it
248 number of common locking errors.
250 There are quite a few other debugging options, some of which will be
251 discussed below. Some of them have a significant performance impact and
252 should not be used all of the time. But some time spent learning the
255 One of the heavier debugging tools is the locking checker, or "lockdep."
256 This tool will track the acquisition and release of every lock (spinlock or
261 lockdep can find a number of scenarios in which the system could, on rare
262 occasion, deadlock. This kind of problem can be painful (for both
264 in an automated manner ahead of time. Code with any sort of non-trivial
269 status of any operation (such as a memory allocation) which can fail. The
270 fact of the matter, though, is that the resulting failure recovery paths
272 you could be much more confident of your code if all those error-handling
277 enabled, a configurable percentage of memory allocations will be made to
278 fail; these failures can be restricted to a specific range of code.
284 Other kinds of errors can be found with the "sparse" static analysis tool.
286 user-space and kernel-space addresses, mixture of big-endian and
287 small-endian quantities, the passing of integer values where a set of bit
294 variety of potential coding problems; it can also propose fixes for those
300 Other kinds of portability errors are best found by compiling your code for
303 step. A large set of cross compilers for x86 systems can be found at
315 of new code into the kernel, make life easier for other developers, and
316 will be helpful for your users. In many cases, the addition of
319 The first piece of documentation for any patch is its associated
321 of the solution, the people who worked on the patch, any relevant
324 worth applying; a surprising number of developers fail to provide that
328 /proc files - should include documentation of that interface which enables
330 Documentation/ABI/README for a description of how this documentation should
333 The file Documentation/kernel-parameters.txt describes all of the kernel's
340 Internal API information for many subsystems is documented by way of
342 in a number of ways by the "kernel-doc" script. If you are working within
347 beginning kernel developers. The format of these comments, along with some
351 Anybody who reads through a significant amount of existing kernel code will
358 Certain things should always be commented. Uses of memory barriers should
362 Non-obvious dependencies between separate bits of code should be pointed
377 There are, of course, some catches. API changes can be made, but they need
379 accompanied by a description of what the change is and why it is
380 necessary. This kind of change should also be broken out into a separate
384 generally charged with the task of fixing any code within the kernel tree
386 lead to literally hundreds or thousands of changes - many of which are
394 This will help you to be sure that you have found all in-tree uses of that
395 interface. It will also alert developers of out-of-tree code that there is
396 a change that they need to respond to. Supporting out-of-tree code is not
398 not have to make life harder for out-of-tree developers than it needs to