From mboxrd@z Thu Jan 1 00:00:00 1970 From: "ira.weiny" Subject: Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Date: Wed, 21 Sep 2016 13:21:29 -0400 Message-ID: <20160921172129.GB27837@phlsvsds.ph.intel.com> References: <20160823185441.GA1233@obsidianresearch.com> <20160825173916.GC20612@obsidianresearch.com> <20160825195246.GI1916@redhat.com> <20160825201306.GA5421@obsidianresearch.com> <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227@redhat.com> <20160828132804.GN594@leon.nu> <20160828183627.GC12783@obsidianresearch.com> <20160829062918.GR594@leon.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Doug Ledford Cc: Leon Romanovsky , Jason Gunthorpe , Jarod Wilson , Steve Wise , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 'Devesh Sharma' , 'Hal Rosenstock' , 'Mike Marciniszyn' , 'Moni Shoua' , 'Sean Hefty' , 'Tatyana Nikolova' , 'Vladimir Sokolovsky' , 'Yishai Hadas' List-Id: linux-rdma@vger.kernel.org > > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html