← Back to branch summary

~ubuntu-branches/ubuntu/precise/linux-ti-omap4/precise

« back to all changes in this revision

Viewing changes to Documentation/development-process/4.Coding

  • Committer: Bazaar Package Importer
  • Author(s): Paolo Pisati
  • Date: 2011-06-29 15:23:51 UTC
  • mfrom: (26.1.1 natty-proposed)
  • Revision ID: james.westby@ubuntu.com-20110629152351-xs96tm303d95rpbk
Tags: 3.0.0-1200.2
* Rebased against 3.0.0-6.7
* BSP from TI based on 3.0.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
Documentation/development-process/4.Coding
131
131
often does not apply to contemporary hardware.  Space *is* time, in that a
132
132
larger program will run slower than one which is more compact.
133
133
 
 
134
More recent compilers take an increasingly active role in deciding whether
 
135
a given function should actually be inlined or not.  So the liberal
 
136
placement of "inline" keywords may not just be excessive; it could also be
 
137
irrelevant.
 
138
 
134
139
 
135
140
* Locking
136
141
 
285
290
distributor does not package it); it can then be run on the code by adding
286
291
"C=1" to your make command.
287
292
 
 
293
The "Coccinelle" tool (http://coccinelle.lip6.fr/) is able to find a wide
 
294
variety of potential coding problems; it can also propose fixes for those
 
295
problems.  Quite a few "semantic patches" for the kernel have been packaged
 
296
under the scripts/coccinelle directory; running "make coccicheck" will run
 
297
through those semantic patches and report on any problems found.  See
 
298
Documentation/coccinelle.txt for more information.
 
299
 
288
300
Other kinds of portability errors are best found by compiling your code for
289
301
other architectures.  If you do not happen to have an S/390 system or a
290
302
Blackfin development board handy, you can still perform the compilation
308
320
changelog.  Log entries should describe the problem being solved, the form
309
321
of the solution, the people who worked on the patch, any relevant
310
322
effects on performance, and anything else that might be needed to
311
 
understand the patch.
 
323
understand the patch.  Be sure that the changelog says *why* the patch is
 
324
worth applying; a surprising number of developers fail to provide that
 
325
information.
312
326
 
313
327
Any code which adds a new user-space interface - including new sysfs or
314
328
/proc files - should include documentation of that interface which enables
321
335
appropriate entries to this file.
322
336
 
323
337
Any new configuration options must be accompanied by help text which
324
 
clearly explains the options and when the user might want to select them. 
 
338
clearly explains the options and when the user might want to select them.
325
339
 
326
340
Internal API information for many subsystems is documented by way of
327
341
specially-formatted comments; these comments can be extracted and formatted
372
386
lead to literally hundreds or thousands of changes - many of which are
373
387
likely to conflict with work being done by other developers.  Needless to
374
388
say, this can be a large job, so it is best to be sure that the
375
 
justification is solid.
 
389
justification is solid.  Note that the Coccinelle tool can help with
 
390
wide-ranging API changes.
376
391
 
377
392
When making an incompatible API change, one should, whenever possible,
378
393
ensure that code which has not been updated is caught by the compiler.