Lines Matching refs:code

5 code.  It is the code which will be examined by other developers and merged
6 (or not) into the mainline tree.  So it is the quality of this code which
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
28 code to the kernel is very difficult if that code is not coded according to
29 the standard; many developers will request that the code be reformatted
30 before they will even review it.  A code base as large as the kernel
31 requires some uniformity of code to make it possible for developers to
33 strangely-formatted code.
37 win before the code can be merged.  Putting code into the kernel means
39 how the code is formatted.
41 The other trap is to assume that code which is already in the kernel is
47 avoided.  It is natural to fix the style of a piece of code while working
62 involving several million lines of code could do otherwise and survive.
70 provides.  By that time, though, chances are good that the code which
80 frowned upon.  Such layers obscure the code and may impose a performance
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
87 replicating the same code throughout the kernel.
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.
100 is used within the kernel.  But there is little desire to see code which is
103 Conditionally-compiled code can be confined to functions which, if the code
106 code which is easier to follow.
111 instead.  The code which results will be the same, but inline functions are
121 however, can actually reduce performance.  Since their code is replicated
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
156 Once upon a time, Linux kernel code could be developed without thinking
161 code could be written without thinking about locking are long past.
165 New code should be written with this requirement in mind; retrofitting
207 For now, at least, the writing of error-free code remains an ideal that few
209 many of those errors as possible before our code goes into the mainline
238  - DEBUG_OBJECTS will add code to track the lifetime of various objects
271 are, probably, completely untested.  Untested code tends to be broken code;
272 you could be much more confident of your code if all those error-handling
278 fail; these failures can be restricted to a specific range of code.
280 code responds when things go badly.  See
290 distributor does not package it); it can then be run on the code by adding
300 Other kinds of portability errors are best found by compiling your code for
315 of new code into the kernel, make life easier for other developers, and
327 Any code which adds a new user-space interface - including new sysfs or
351 Anybody who reads through a significant amount of existing kernel code will
353 the expectations for new code are higher than they were in the past;
354 merging uncommented code will be harder.  That said, there is little desire
355 for verbosely-commented code.  The code should, itself, be readable, with
362 Non-obvious dependencies between separate bits of code should be pointed
363 out.  Anything which might tempt a code janitor to make an incorrect
384 generally charged with the task of fixing any code within the kernel tree
393 ensure that code which has not been updated is caught by the compiler.
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