> Now, given that this API is stand-alone right now, it could still be added
> to either libibumad or to libibverbs - but I like Sean's suggestion that it
> be added to verbs, since the current security model restricts libibumad to
> root access and because the existing API already makes use of libibverbs'
> ibv_context data structure.
Did we ever reach any consensus on this?
> int ibv_sa_register_inform_info(struct ibv_sa_event_channel *channel,
> struct ibv_context *device, uint8_t
> port_num,
> uint16_t trap_number, void *context,
> struct ibv_sa_id **id);
Would something like this work for you?
enum ibv_event_type {
...
+ IBV_EVENT_SA
...
struct ibv_async_event {
union {
+ struct ibv_sa_event *sa_event;
...
+ int ibv_reg_sa_event(struct ibv_context *context, uint8_t port_num,
uint16_t trap_number);
This would tie in with the libibverbs async event reporting and provide a
simple registration API. (Deregistering would just be done automatically when
closing the ibv_context.)
Roland, do you have any thoughts about extending libibverbs/uverbs in this way?
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
