> > > > > + filp = ib_uverbs_alloc_event_file(file, ib_dev, 1);
> > > > > + if (IS_ERR(filp)) {
> > > > > + ret = PTR_ERR(filp);
> > > > > + goto err_fd;
> > > > > + }
> > > >
> > > > I was considering events being reported directly on the file that's
> > > > already opened. Any objects opened through a file would report
> > > > their events on that file, with possibly a way to redirect events to
> > > > a different file (similar to rdma_migrate_id processing).
> > >
> > > Is this code then just an optional compat for libibverbs 1.0?
> >
> > It can work for compat, but migrate id had other use cases, which
> > might be applicable in other situations.
>
> Sorry, I ment the code you are quoting.
>
> Eg, should the above have the 'struct ib_uverbs_get_context_resp'
> redone to not include the 'resp.async_fd' and a new method call be required
> to get the events filp?
That's likely to be more generic.
> compat libibverbs 1.0 would always have to call the new method.
>
> If we had a new libibverbs 2.0 event delivery scheme like you envision
> then 2.0 would call a different method instead to setup the new
> scheme.
I was not attempting to provide a compatibility layer to verbs. I was developing a generic framework to support all devices, verbs or otherwise. If done correctly, compatibility should fall out naturally. My immediate objective was to hook hfi1 into this framework. Hooking verbs into it is a much lower priority to me, as we already have a working solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
