> > > > > > Do we want to create rdma-tools after this task will be > > > > > completed? For > > > example > > > > > with debug and performance tools in it. > > > > > > > > Prolification of repositories is exactly what this is intended to > > > > prevent :( > > > > > > The goal would be to move all the tools/cmds/etc into one repo. How > > > is that prolification? > > > > I guess I should wait and see what could end up in there before > > commenting... > > > > I think we should shelf this discussion until we get our current project done... > > But... :) > > A quick gander at the OFED packages produces this list of possible > candidates: > > dapl (perhaps dapl should be in rdma-plumbing?) fabtests ibacm ibpd ibsim > ibutils infiniband-diags infinipath-psm mstflint opensm perftest qlvnictools > qperf rds-tools I strongly suggest against adding anything that is not a library and even then I like what Jason has said previously. "This is a library targeted for kernel APIs." So, for example, libibmad was not included. In fact architecturally I think ibmad should go away somehow. The main user is infiniband-diags but there are some other users of it so I have not been able to deprecate it. I guess my opinion is I don't want to see this repo become "OFED" in a different form. There are valid reasons to have separate packages. It is really the support libraries which have been a pain. 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 -- 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
