[Ofvwg] Further thoughts on uAPI

[Hefty, Sean]

> Study of objects:
>  'device','port' - Pre-existing and read-only, query_object returns
>                    information like we have today
>  'pd','mr','mw','cq','srq','qp','ah' - Basic objects, not all have a
> modify/query
>  'flow','xrc',etc - extra objects

IMO, we should examine what items are objects.  E.g. and XRC RQ is treated as a QP, whereas an SRQ is not.  It may make more sense to treat each QP type as separate objects.  It would definitely make the data structures more efficient and a lot more understandable.

> Additional entry points:
>  poll_cq/req_notify_cq - These are high speed, so simple ioctls, or
>                          driver specific
>  post recv/send - drivers implement these via call_driver_on_object
>  attach/detach mcast - Could be 'modify' a qp, or could be new ioctls
>  async_event - Should be an ioctl
>  get_fd - Convert the object to a fd (eg async_fd, comp_channel, etc)

We could define a generic event_channel/event_queue object to report asynchronous events.  The EQ could then be associated with a device, port, CQ, CM objects (e.g. QP), etc.  User space could achieve current semantics by limiting which objects are associated with each channel.