| 1 |
583 |
jeremybenn |
1 Introduction
|
| 2 |
|
|
|
| 3 |
|
|
This document describes some guidelines for people participating
|
| 4 |
|
|
in lwIP development.
|
| 5 |
|
|
|
| 6 |
|
|
2 How to contribute to lwIP
|
| 7 |
|
|
|
| 8 |
|
|
Here is a short list of suggestions to anybody working with lwIP and
|
| 9 |
|
|
trying to contribute bug reports, fixes, enhancements, platform ports etc.
|
| 10 |
|
|
First of all as you may already know lwIP is a volunteer project so feedback
|
| 11 |
|
|
to fixes or questions might often come late. Hopefully the bug and patch tracking
|
| 12 |
|
|
features of Savannah help us not lose users' input.
|
| 13 |
|
|
|
| 14 |
|
|
2.1 Source code style:
|
| 15 |
|
|
|
| 16 |
|
|
1. do not use tabs.
|
| 17 |
|
|
2. indentation is two spaces per level (i.e. per tab).
|
| 18 |
|
|
3. end debug messages with a trailing newline (\n).
|
| 19 |
|
|
4. one space between keyword and opening bracket.
|
| 20 |
|
|
5. no space between function and opening bracket.
|
| 21 |
|
|
6. one space and no newline before opening curly braces of a block.
|
| 22 |
|
|
7. closing curly brace on a single line.
|
| 23 |
|
|
8. spaces surrounding assignment and comparisons.
|
| 24 |
|
|
9. use current source code style as further reference.
|
| 25 |
|
|
|
| 26 |
|
|
2.2 Source code documentation style:
|
| 27 |
|
|
|
| 28 |
|
|
1. JavaDoc compliant and Doxygen compatible.
|
| 29 |
|
|
2. Function documentation above functions in .c files, not .h files.
|
| 30 |
|
|
(This forces you to synchronize documentation and implementation.)
|
| 31 |
|
|
3. Use current documentation style as further reference.
|
| 32 |
|
|
|
| 33 |
|
|
2.3 Bug reports and patches:
|
| 34 |
|
|
|
| 35 |
|
|
1. Make sure you are reporting bugs or send patches against the latest
|
| 36 |
|
|
sources. (From the latest release and/or the current CVS sources.)
|
| 37 |
|
|
2. If you think you found a bug make sure it's not already filed in the
|
| 38 |
|
|
bugtracker at Savannah.
|
| 39 |
|
|
3. If you have a fix put the patch on Savannah. If it is a patch that affects
|
| 40 |
|
|
both core and arch specific stuff please separate them so that the core can
|
| 41 |
|
|
be applied separately while leaving the other patch 'open'. The prefered way
|
| 42 |
|
|
is to NOT touch archs you can't test and let maintainers take care of them.
|
| 43 |
|
|
This is a good way to see if they are used at all - the same goes for unix
|
| 44 |
|
|
netifs except tapif.
|
| 45 |
|
|
4. Do not file a bug and post a fix to it to the patch area. Either a bug report
|
| 46 |
|
|
or a patch will be enough.
|
| 47 |
|
|
If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.
|
| 48 |
|
|
5. Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two)
|
| 49 |
|
|
can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded
|
| 50 |
|
|
as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead
|
| 51 |
|
|
for reporting a compiler warning fix.
|
| 52 |
|
|
6. Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other
|
| 53 |
|
|
trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you
|
| 54 |
|
|
change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than
|
| 55 |
|
|
if it's not to the point and long :) so the chances for it to be applied are greater.
|
| 56 |
|
|
|
| 57 |
|
|
2.4 Platform porters:
|
| 58 |
|
|
|
| 59 |
|
|
1. If you have ported lwIP to a platform (an OS, a uC/processor or a combination of these) and
|
| 60 |
|
|
you think it could benefit others[1] you might want discuss this on the mailing list. You
|
| 61 |
|
|
can also ask for CVS access to submit and maintain your port in the contrib CVS module.
|
| 62 |
|
|
|
