Lines Matching full: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
85 At a simple level, consider a function which has an argument which is
88 provides.  By that time, though, chances are good that the code which
89 implements this extra argument has been broken in some subtle way which was
91 extra flexibility arises, it does not do so in a way which matches the
96 Abstraction layers which hide access to hardware - often to allow the bulk
114 use of it results in code which is much harder for others to read and
116 is almost always a sign of code which needs some cleanup work.
119 is used within the kernel.  But there is little desire to see code which is
122 Conditionally-compiled code can be confined to functions which, if the code
125 code which is easier to follow.
130 instead.  The code which results will be the same, but inline functions are
143 That, in turn, creates pressure on the processor's memory caches, which can
152 larger program will run slower than one which is more compact.
184 Any resource (data structures, hardware registers, etc.) which could be
189 enough to pick the right tool for the job.  Code which shows a lack of
197 change (which may bring big improvements) which causes something to break
200 exceptions, changes which cause regressions will be backed out if the
235 array of tools which can catch a wide variety of obscure problems in an
236 automated way.  Any problem caught by the computer is a problem which will
245 and try to avoid "fixes" which make the warning go away without addressing
251 The kernel provides several configuration options which turn on debugging
262    you are adding a subsystem which creates (and exports) complex objects
272 There are quite a few other debugging options, some of which will be
279 mutex) in the system, the order in which locks are acquired relative to
283 lockdep can find a number of scenarios in which the system could, on rare
291 status of any operation (such as a memory allocation) which can fail.  The
297 The kernel provides a fault injection framework which can do exactly that,
351 Any code which adds a new user-space interface - including new sysfs or
352 /proc files - should include documentation of that interface which enables
359 Any patch which adds new parameters should add the appropriate entries to
362 Any new configuration options must be accompanied by help text which
368 a subsystem which has kerneldoc comments, you should maintain them and add
370 which have not been so documented, there is no harm in adding kerneldoc
388 out.  Anything which might tempt a code janitor to make an incorrect
411 which is broken by the change.  For a widely-used function, this duty can
412 lead to literally hundreds or thousands of changes - many of which are
419 ensure that code which has not been updated is caught by the compiler.