Lines Matching refs:which

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
10 number of ways in which kernel developers can go wrong.  Then the focus
11 will shift toward doing things right and the tools which can help in that
22 a substantial amount of code in the kernel which does not meet the coding
41 The other trap is to assume that code which is already in the kernel is
51 The coding style document also should not be read as an absolute law which
53 style (a line which becomes far less readable if split to fit within the
67 At a simple level, consider a function which has an argument which is
70 provides.  By that time, though, chances are good that the code which
71 implements this extra argument has been broken in some subtle way which was
73 extra flexibility arises, it does not do so in a way which matches the
78 Abstraction layers which hide access to hardware - often to allow the bulk
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
123 That, in turn, creates pressure on the processor's memory caches, which can
132 larger program will run slower than one which is more compact.
163 Any resource (data structures, hardware registers, etc.) which could be
168 enough to pick the right tool for the job.  Code which shows a lack of
175 change (which may bring big improvements) which causes something to break
178 exceptions, changes which cause regressions will be backed out if the
211 array of tools which can catch a wide variety of obscure problems in an
212 automated way.  Any problem caught by the computer is a problem which will
221 and try to avoid "fixes" which make the warning go away without addressing
227 The kernel provides several configuration options which turn on debugging
240    you are adding a subsystem which creates (and exports) complex objects
250 There are quite a few other debugging options, some of which will be
257 mutex) in the system, the order in which locks are acquired relative to
261 lockdep can find a number of scenarios in which the system could, on rare
269 status of any operation (such as a memory allocation) which can fail.  The
275 The kernel provides a fault injection framework which can do exactly that,
327 Any code which adds a new user-space interface - including new sysfs or
328 /proc files - should include documentation of that interface which enables
334 boot-time parameters.  Any patch which adds new parameters should add the
337 Any new configuration options must be accompanied by help text which
343 a subsystem which has kerneldoc comments, you should maintain them and add
345 which have not been so documented, there is no harm in adding kerneldoc
363 out.  Anything which might tempt a code janitor to make an incorrect
385 which is broken by the change.  For a widely-used function, this duty can
386 lead to literally hundreds or thousands of changes - many of which are
393 ensure that code which has not been updated is caught by the compiler.