Lines Matching refs:which

8 code.  It is the code which will be examined by other developers and merged
9 (or not) into the mainline tree.  So it is the quality of this code which
13 number of ways in which kernel developers can go wrong.  Then the focus
14 will shift toward doing things right and the tools which can help in that
28 which does not meet the coding style guidelines.  The presence of that code
46 The other trap is to assume that code which is already in the kernel is
56 The coding style document also should not be read as an absolute law which
58 style (a line which becomes far less readable if split to fit within the
81 At a simple level, consider a function which has an argument which is
84 provides.  By that time, though, chances are good that the code which
85 implements this extra argument has been broken in some subtle way which was
87 extra flexibility arises, it does not do so in a way which matches the
92 Abstraction layers which hide access to hardware - often to allow the bulk
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.
115 is used within the kernel.  But there is little desire to see code which is
118 Conditionally-compiled code can be confined to functions which, if the code
121 code which is easier to follow.
126 instead.  The code which results will be the same, but inline functions are
139 That, in turn, creates pressure on the processor's memory caches, which can
148 larger program will run slower than one which is more compact.
180 Any resource (data structures, hardware registers, etc.) which could be
185 enough to pick the right tool for the job.  Code which shows a lack of
193 change (which may bring big improvements) which causes something to break
196 exceptions, changes which cause regressions will be backed out if the
231 array of tools which can catch a wide variety of obscure problems in an
232 automated way.  Any problem caught by the computer is a problem which will
241 and try to avoid "fixes" which make the warning go away without addressing
247 The kernel provides several configuration options which turn on debugging
260    you are adding a subsystem which creates (and exports) complex objects
270 There are quite a few other debugging options, some of which will be
277 mutex) in the system, the order in which locks are acquired relative to
281 lockdep can find a number of scenarios in which the system could, on rare
289 status of any operation (such as a memory allocation) which can fail.  The
295 The kernel provides a fault injection framework which can do exactly that,
349 Any code which adds a new user-space interface - including new sysfs or
350 /proc files - should include documentation of that interface which enables
357 Any patch which adds new parameters should add the appropriate entries to
360 Any new configuration options must be accompanied by help text which
366 a subsystem which has kerneldoc comments, you should maintain them and add
368 which have not been so documented, there is no harm in adding kerneldoc
386 out.  Anything which might tempt a code janitor to make an incorrect
409 which is broken by the change.  For a widely-used function, this duty can
410 lead to literally hundreds or thousands of changes - many of which are
417 ensure that code which has not been updated is caught by the compiler.