Contributing to the OpenDataplane (ODP) API

  The ODP API follows the linux kernel coding style [1] and code submission
process [2], albeit patch submissions are to be submitted to the ODP
linaro-networking mailing list [3] (not LKML, etc.). ODP targets the C99 standard
and code should refrain from using gcc specific extensions in the interface and
in the linux-generic implementation or examples.

  To certify you wrote the code, or otherwise have the right to pass it
on (presumably from a compatibly licensed project), we use the "Developer's
Certificate of Origin" (see [2]).  Using this sign-off process, we are able to
keep track of compliance to our license (see LICENSE file).

  There are tools we use to maintain CodingStyle and other good programming
practice consistency, including type-checking without overuse of casts.

(a) perform a one-time setup for the tools:

semantic parser 'sparse' [4]:

	git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git
	cd sparse
	make
	export PATH=$PATH:$PWD

(b) when building, use sparse to check for stricter type checking than the
compiler:

	make CC=cgcc

(c) create patches with git:
	git format-patch --subject-prefix="PATCH"  --find-renames HEAD^
	For prefixes see [3].

(d) Prior to submission, to style-check the patch 'file.patch', run:

	./scripts/checkpatch.pl file.patch

    Note: A common issue that causes patches to fail checkpatch is the
    presense of trailing whitespace.  Emacs users can use the command:

    Meta-X delete-trailing-whitespace

    to scrub the file prior to saving to avoid these issues.  Vim users
    can accomplish the same with the command:

    :%s/\s\+$//

    Please ensure submitted patches are checkpatch clean before submitting
    them to avoid having them automatically returned for rework.

Documenting the code

    Allow doxygen to use all its default behaviors to identify tagged
    information but where a doxygen tag must be specified use @

    The first line is by default the brief summary.

    The next paragraph is by default the detailed summary

    Normal comment sections should be before the code block and start with
    /** on its own line and finish with */ on its own line. The exception
    to this rule is a case where the comment is very small, for example
    /** macro description */
    #define SOME_MACRO 0

    Commenting on the end of a line for macros and struct members is allowed using /**< <text> */ for example
    #define SOME_MACRO 0 /**< <text> */

    Files should start with a files description using @file

    Functions should specify their parameters with @param[in] and @param[out]

    Functions return values should all be specified using @return

    There should be no doxygen warnings or errors generated.

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
[3] refer to README file.
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/sparse.txt