[ofw] typical values for ci_umv_buf_t

[Fab Tillier]

There would need to be a way for the UVP to figure out which device to open a file handle on, a mechanism that today does not exist.  If it opens a new file on the IBAL device, it needs to also associate it with the existing open context, again something that's internal to IBAL.

You'll need to give the UVP one of IBAL's file handles (whether an existing or a new one doesn't matter - there's already mechanisms inside IBAL to handle multiple files per application context).  Maybe put this as an input to the pre-open-ca call?

This does lay the foundation for having the HCA driver manage its own IOCTLs, though allows IBAL to own the logic of where the file object should be created which I think you want.

-Fab

-----Original Message-----
From: Sean Hefty [mailto:sean.hefty at intel.com]
Sent: Tuesday, March 18, 2008 10:00 AM
To: 'Reuven Amitai'; Fab Tillier; Leonid Keller; ofw at lists.openfabrics.org
Subject: RE: [ofw] typical values for ci_umv_buf_t

>IBAL calls uvp:post() in query_av verb even when the uvp:pre() returns
>IB_VERBS_PROCESSING_DONE
>in order to return pd (which absent in the pre() prototype)
>I think there is no need for that in create_av verb.

What about the following idea?

Add new AV calls to the uvp3_interface_t structure that I mentioned in my other
email to create/destroy address vectors.  Internally to the existing uvp, these
would just call the current pre/post routines.

A new uvp that wanted to implement these calls would simply either have to do
everything in userspace, or perform their own IOCTLs to the kernel WV driver.
(The IOCTLs would be defined, but missing the kernel implementation until it's
actually needed by someone.)

I think this would be cleaner than trying to handle IB_VERBS_PROCESSING_DONE.

- Sean