[ofw] [RFC] [PATCH] winverbs: convert ib_api_status to wvstatus

[Sean Hefty]

>Why are some many IBAL errors coalesced into a single WV error?
>Example:
>> -//	case IB_INVALID_QP_STATE:		return WV_INVALID_PARAMETER;
>> -//	case IB_INVALID_APM_STATE:		return WV_INVALID_PARAMETER;
>> -//	case IB_INVALID_PORT_STATE:		return WV_INVALID_PARAMETER;
>> -//	case IB_INVALID_STATE:			return WV_INVALID_PARAMETER;
>
>> -//	case IB_INVALID_GID:			return WV_INVALID_ADDRESS;
>> -//	case IB_INVALID_LID:			return WV_INVALID_ADDRESS;
>> -//	case IB_INVALID_GUID:			return WV_INVALID_ADDRESS;
>
>Seems useful debug info is lost?

There are several answers to this:

The main reason is that I haven't spent the time to define all possible error
codes.  I plan on looking at that when implementing each call, rather than
trying to guess everything up front.  I don't know what ib_api_status_t values
I'll actually need to use yet.

I don't intend on having winverbs validate all parameters in userspace, and
instead rely on assertions.  (E.g. an app that passes in a NULL value to a
function is not a run time error that's recoverable.  It's an error that
requires program changes.)  This will speed up program execution.

Multiple values can sometimes map to a single value based on the context of the
call, and there are defines for INVALID_PARAMETER1, INVALID_PARAMETER2, etc.  In
many cases those would be used instead, but those need to be mapped on a per
call basis.  This is because the winverbs APIs typically take multiple
parameters as input, rather than structures. 

When mapping the return values up to NDI or OFED verbs, the additional return
information gets lost anyway.

- Sean