Lines Matching full:be
6 While there is much to be said for a solid and community-oriented design
8 code. It is the code which will be examined by other developers and merged
34 the standard; many developers will request that the code be reformatted
42 win before the code can be merged. Putting code into the kernel means
53 on it for other reasons, but coding style changes should not be made for
56 The coding style document also should not be read as an absolute law which
57 can never be transgressed. If there is a good reason to go against the
77 But experience has shown that excessive or premature abstraction can be
78 just as harmful as premature optimization. Abstraction should be used to
89 patches to remove unused arguments; they should, in general, not be added
93 of a driver to be used with multiple operating systems - are especially
117 should be confined to header files whenever possible.
118 Conditionally-compiled code can be confined to functions which, if the code
119 is not to be present, simply become empty. The compiler will then quietly
126 instead. The code which results will be the same, but inline functions are
140 slow execution dramatically. Inline functions, as a rule, should be quite
151 a given function should actually be inlined or not. So the liberal
152 placement of "inline" keywords may not just be excessive; it could also be
170 (now called mac80211) could be merged, a locking scheme needed to be
173 Once upon a time, Linux kernel code could be developed without thinking
178 code could be written without thinking about locking are long past.
180 Any resource (data structures, hardware registers, etc.) which could be
181 accessed concurrently by more than one thread must be protected by a lock.
182 New code should be written with this requirement in mind; retrofitting
192 One final hazard worth mentioning is this: it can be tempting to make a
196 exceptions, changes which cause regressions will be backed out if the
197 regression cannot be fixed in a timely manner. Far better to avoid the
200 It is often argued that a regression can be justified if it causes things
217 be supported indefinitely. This fact makes the creation of user-space
218 interfaces particularly challenging: since they cannot be changed in
219 incompatible ways, they must be done right the first time. For this
234 tools should be used whenever possible.
249 of these options should be turned on for any kernel used for development or
255 generated by these warnings can be verbose, but one need not worry about
265 should be used on most development kernels.
270 There are quite a few other debugging options, some of which will be
272 should not be used all of the time. But some time spent learning the
273 available options will likely be paid back many times over in short order.
282 occasion, deadlock. This kind of problem can be painful (for both
283 developers and users) in a deployed system; lockdep allows them to be found
285 locking should be run with lockdep enabled before being submitted for
291 are, probably, completely untested. Untested code tends to be broken code;
292 you could be much more confident of your code if all those error-handling
297 enabled, a configurable percentage of memory allocations will be made to
298 fail; these failures can be restricted to a specific range of code.
304 Other kinds of errors can be found with the "sparse" static analysis tool.
305 With sparse, the programmer can be warned about confusion between
308 flags is expected, and so on. Sparse must be installed separately (it can
309 be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your
310 distributor does not package it); it can then be run on the code by adding
324 step. A large set of cross compilers for x86 systems can be found at
338 will be helpful for your users. In many cases, the addition of
344 effects on performance, and anything else that might be needed to
345 understand the patch. Be sure that the changelog says *why* the patch is
353 be formatted and what information needs to be provided.
360 Any new configuration options must be accompanied by help text which
364 specially-formatted comments; these comments can be extracted and formatted
369 comments for the future; indeed, this can be a useful activity for
371 information on how to create kerneldoc templates can be found at
377 merging uncommented code will be harder. That said, there is little desire
378 for verbosely-commented code. The code should, itself, be readable, with
381 Certain things should always be commented. Uses of memory barriers should
382 be accompanied by a line explaining why the barrier is necessary. The
383 locking rules for data structures generally need to be explained somewhere.
385 Non-obvious dependencies between separate bits of code should be pointed
393 The binary interface provided by the kernel to user space cannot be broken
395 programming interfaces, instead, are highly fluid and can be changed when
398 needs, that may be a sign that the API needs to change. As a kernel
401 There are, of course, some catches. API changes can be made, but they need
402 to be well justified. So any patch making an internal API change should be
404 necessary. This kind of change should also be broken out into a separate
412 say, this can be a large job, so it is best to be sure that the
418 This will help you to be sure that you have found all in-tree uses of that
421 something that kernel developers need to be worried about, but we also do
423 be.