[ofw] [RFC] winverbs implementation approach

[Sean Hefty]

>1) Once there is an error, please also trace it. This makes debugging
>much easier.

I still need to add debug support in.

>2) The current code allocates memory from the heap for every operation
>and frees it later.
>Allocating memory is relatively an expensive task and should be avoided
>if possibale.
>One possibale way to do that is to use a buffer on the heap for most
>ioctls and allocate only if there is a need for a bigger buffer.

There is an allocation in userspace to account for the uvp data, but this is to
avoid the allocation and copy from user done in the kernel.  I've thought about
adding padding to the end of WV structures to account for the uvp data, which
would allow direct use of stack variables, with allocations only done if needed.
(I picked the simple approach to start with, which was always allocate, since I
don't know that anything with a pre/post call are really speed path operations.)
I will see about avoiding the allocations.

I'm guessing that the current uvp in/out sizes are related to the struct sizes
that are defined in mx_abi.h.  Create CQ needs about 96 bytes.  The QP calls
look like they need more.

Even longer term, I think it may be more efficient to have the uvp issue IOCTLs
directly to the winverb kernel driver.  But this is an intrusive change that
could be phased in over time if it showed to provide any benefit. 

>3) My recommendation is not to have a return in the middle of a function
>but to use the "goto cleanup" mechanism. From my experience this makes
>the code more maintainable.

I do this unless I'm returning early in the function where cleanup isn't
necessary, and the goto jumps directly to the return.

>4) In the case of an error in allocating the memory, the call to
>post_create_cq is not done. Is this by intention?

It was an oversight.  It occurred to me last night that the post*() calls need
to be called if pre*() returned success.

- Sean