[ofw] RE: [PATCH] Support for ND over WV (incomplete)

[Sean Hefty]

>Here's the prototype for the DisconnectAndFlush method that would be needed for
>an ND provider over WV.
>
>I don't have any code to implement that, but for now it could be implemented as
>returning an error status.  This mainly gets the WV interfaces in place for the
>2.1 release.
>
>Hopefully not too many things pop up when we get to the actual implementation.
>
>I changed the interface GUID since the interface changed.
>
>Thoughts/comments?

I believe these are the issues that need to be dealt with:

- We can safely modify the QP state to error when:
	a) a DREQ has been received
	b) a DREP has been received
- CM callbacks are at dispatch.
- For a) we can modify to error in the downcall from userspace
  We just need to know if a DREQ has been received
  (Note that all other QP modify calls are done in downcalls.)
- For b) we cannot call modify in the CM callback

The last bullet is what needs to be dealt with.  The kernel could store the
QpId with the WV_ENDPOINT structure when EP:Accept() is called, but it still
needs to queue the modify call to another thread. 

The WV ND provider could probably handle this by allocating a thread and
separating the ND:Disconnect call into two WV calls, Disconnect and Modify.  It
should be possible to handle this in the kernel as well, but it still requires a
thread switch.  I think we need to look at the advantages of these two
approaches, unless someone can come up with a third approach.

The only advantage I can think of for handling this in the kernel depends on
having a QP modify call that can occur at dispatch.  Regardless of which
approach is used, I think we can handle it without changing the API or IOCTL
interfaces.

- Sean