Home

What This Is

The libfabric project is intended to be a user space library that provides a common API for programming to multiple, disparate RDMA capable fabrics. It abstracts out the details of those specific fabrics and provides a common method to access their various features.

Who We Are

We are an independent group of people that saw a common need for a new user space API for RMDA programming that is not so strictly tied to the IniniBand Verbs API abstraction. We include hardware vendors, software vendors, and consumers from a wide variety of fields and vertical interests.

How To Contribute

You can start by cloning this repo and starting to familiarize yourself with the code (preferably, if you have a github account, first fork the repo to your own account, then clone that repo to your local machine...that way you will have the option of either pushing your work to your fork of the repo and then issuing pull requests or you can send patch sets to the email list). While you are spending your copious free time reading endless header files and struct definitions, you can also join the mailing list. It's open to subscribers. The list is ofiwg@lists.openfabrics.org and can be subscribed to by going to the mailman list info page.

Feel free to introduce yourself to the group. We'll do our best to make you feel welcome and put you immediately to work ;-)

Once you are ready to send in some code, there a few housekeeping items you should know:

• This project is under a dual license: BSD or GPLv2. If your code contributions can not be given under this license scheme, then we can't accept it.
• All code submissions must be encumbrance free. This does not necessarily mean that the code is free of any Intellectual Property, but it does mean that you are granting this project (and subsequently any other open source projects) the right to use that code royalty free in perpetuity in accordance with the patent terms of both the BSD and GPLv2 licenses.
• All patches should contain a Signed-Off-By: line to indicate your agreement with the above.
• The coding style of this project resembles that of the linux kernel, please match your contributions to the prevailing style in the files.
• Explain anything non-obvious in code comments. This is especially true of locking changes.
• This is a shared library that utilizes the libtool numbering scheme. Familiarize yourself with libtool and the requirements that warrant a bump in libtool versions and if your changes meet those requirements, clearly spell out why you think we need to rev the library ABI version for your changes.
• Test your changes, and prior to submission, rebase your work on the tip of the tree and test again just to make sure it still applies/works in case the head of the repo has changed since you started your work.
• Either push your work to your local fork and issue a pull request (preferred method), or send your patch set to the mailing list for review.
• Follow good git change practices. There are many sites that have spelled this out in great detail, but it basically boils down to these key items:
  1. All changes should be self contained, meaning that the code should both compile and work before the change and after the change.
  2. All changes should be a single change. Don't mix a locking fix and typo corrections and feature enhancement into a single change.
  3. The first line of your commit message is the line used when viewing the shortlog. Keep that line short and make it a succinct summary of your changes. Skip one line, then write a detailed change log that explains your work in sufficient detail that it can be easily followed.
• Prepare to have your work reviewed and to possibly be asked to rework it, or to have it rejected. Don't take it personally, we've all been there. It's part of what makes open source software higher quality than it otherwise might be. We all benefit from constructive criticism from time to time ;-)