> > Unfortunataely, what you speak of is not really realistic, both for the > reasons I've cited and a whole litany of other reasons I didn't mention. > > But I don't think Jason jumped in to work on this because of the goal of > making Red Hat's life easier in packaging up the separate code. He did > it for upstream related reasons: > > 1) Put all of the providers and libibverbs in one place so that they can > be kept in sync. This allows us to do the exact same thing we do with > the kernel in user space. Namely, if someone makes an incompatible > change in the libibverbs core, we can require that they fix up all > providers in the same patch series. This works rather well for the > kernel, and it would be good to bring that policy to user space too. > > 2) Put all of the kernel interacting libraries in one place. This makes > it easier to perform the write->ioctl conversion we've been discussing > as there would be only one larger package that needs to be updated for > any given kernel ioctl update. > > 3) Bring librdmacm and libibverbs together so that the occasional > incompatible update between the two is not an issue any more. > > 4) Create an easier to build/install package for developers to use. > > Those are the issues we should be discussing the relative merits of in > order to determine whether this work should be adopted. > I see one more benefit here. This should give us an opportunity to consolidate and clarify the interface to the _users_ of these libraries. For example it has always bothered me is there are about 3 places that a PathRecord struct was defined. To be clear I think PathRecords should be hidden from the user but in general keeping a clean interface to the user between librdmacm, libibverbs, and to a lesser extent (or maybe not at all) libibumad would be very nice for the end user. Ira -- 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
