IbAccess Infiniband transport stack and agents

Makefile design:

IbAccess can be built for multiple OS types.  A large percentage of the code

is designed to be portable.  However there are OS specific portions.

Primary directory layout is as follows:

Common - portable code for kernel mode and where the same user mode functions

UserCommon - portable code for user mode only

X - kernel code for OS X (Linux, Win2K, etc)

UserX - user mode code for OS X (Linux, Win2K, etc) when applicable

READMEs in the X and UserX trees document the major functionality in each

	directory

The makefiles are implemented strictly in the X and UserX directory trees.

In those directories each Makefile follows the standard

"module level" makefile style as generated by buildMakefile -c Common/...

For example in Linux/Ibt/Cm use:

	buildMakefile -c Common/Ibt/Cm

The -c option causes the following additions to a basic Makefile

COMMON_SRCDIR - is defined as the path to a peer Common directory (-c option)

	for example: $(MOD_DIR)/Common/Ibt/Sma

	This is used in Makerules.module to guide VPATH and MOD_INCLUDE_DIRS

	to allow the given X/UserX Makefile to compile code in COMMON_SRCDIR

CFILES - files which are to be compiled from the local directory (directory

	Makefile appears in) as well as files to be compiled from COMMON_SRCDIR

	due to VPATH in Makerules.module, simple filenames must be listed for each.

INCLUDE_TARGETS - files which are to be public includes from the local

	directory and the COMMON_SRCDIR.  Here the files in the COMMON_SRCDIR

	must be listed as full paths (eg. $(COMMON_SRCDIR)/header.h).

The Makefiles for Each OS can decide which common files need to be compiled

and exported.

In some cases a given OS may only need a subset of the common capabilities

(especially from the OsAbstraction/Public component).

Those which are disabled are moved below the "Add more x files here" line

and are commented out (note that due to \ missing on "Add more ..." line

there is no problem with leaving a backslash at the end of these commented

out lines.)

To Add a VPD Interface:

edit vpd_export.h, and update VPD_INTERFACE_VERSION_LATEST in enum (add a new

enum value).

update vca to use the interface

update Verbs Drivers to:

	- report new interface version in VcaRegisterVpd3 (always use explicit not LATEST)

	- implement new interface

	- update va_verbs value returned

No need to rename VcaRegisterVpd nor VPD_KM_INTERFACE

To add a UVP Interface:

edit uvp_export.h and update UVP_INTERFACE_VERSION_LATEST in enum (add a new enum value)

update uvca to use the interface

update UVP Verbs drivers to:

	- return new interface version in GetVersion (always use explicit not LATEST)

	- implement new interface

	- update Interface function table value returned

No need to rename UVP_INTERFACE

To add a Verbs interface:

- implement function in vca (iba_*) and export it (use an existing

	function such as iba_post_send as an example of what is needed

- update vpi_export.h to export the function (no need to add to deprecated

	VPI_KM_INTERFACE)

- implement function in uvca (iba_*) (see an existing function)

- update uvca_export.h to export the function (no need to add to deprecated

	VPI_UM_INTERFACE)

- update IBT_VERSION to next number

- as needed add to UVP and/or VPD interface (see above)

For windows declare IBA_API in UserWindows/../datatypes_osd.h as follows:

#ifdef _IBA_API_EXPORTS_

#undef IBA_API

#define IBA_API __declspec(dllexport)

#else

#undef IBA_API

#define IBA_API __declspec(dllimport)

#endif // _IBA_API_EXPORTS_