[ovs-dev] [PATCH 0/9] RFC: rework code base for third-party linking

[Ben Pfaff]

On Mon, Feb 22, 2016 at 03:46:50PM -0800, ben at skyportsystems.com wrote:
> - There may not seem to be much rhyme or reason as to the ordering of #include
>   directives in source files.  My OCD pushes me towards always using a particular
>   pattern, usually alphabetic with files in directories going first, but many of
>   changes I made here were done using 'sed -i' which doesn't affect line ordering.
>   I'd gladly fix these up if anybody has a preference, but there didn't seem to be
>   any obvious rules in place.

CodingStyle has some rules; they're not always followed:

      The first non-comment line in a .c source file should be:

        #include <config.h>

    `#include` directives should appear in the following order:

    1. `#include <config.h>`

    2. The module's own headers, if any.  Including this before any
       other header (besides <config.h>) ensures that the module's
       header file is self-contained (see HEADER FILES) below.

    3. Standard C library headers and other system headers, preferably
       in alphabetical order.  (Occasionally one encounters a set of
       system headers that must be included in a particular order, in
       which case that order must take precedence.)

    4. Open vSwitch headers, in alphabetical order.  Use "", not <>,
       to specify Open vSwitch header names.

> Going Forward:
> 
> - While the code and macros in 'list.h' have pretty good namespace protection,
>   we should probably do some work on 'util.h', and I'm sure there are others.
> - Maybe we should add explicit namespace to the files in 'include'?

Yes, probably on both of those.

util.h probably should get broken up these days.  It has some categories
of functions that could easily get their own header files, e.g. a header
file for bitwise functions.