README
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_