On Wed, 25 Feb 2004, Linus Torvalds wrote:
>Oh, I agree that _reviewing_ code is good, together with feedback
>on what would improve its chances of getting accepted later on.
>But it should be clear that regardless,
>we don't add features that nobody
>can sanely test and where hardware isn't available.
>
> Linus
Just wanted to give an update on where we are with the InfiniBand IBAL.
After we submitted the IBAL code for review, there has been additional
InfiniBand code put into open source by the major InfiniBand companies,
namely TopSpin, Mellanox, InfiniCon, and Voltaire.
This presents somewhat of a problem because now there are multiple
versions of the various InfiniBand S/W components, Access Layers, and
ULPs.
We now need to review all this code and
determine which code is best to use as a basis for something that
we would eventually try to get into Linux. We hope that people in the
linux community will help us sort through this mess and come up with
a "best of breed" stack out of all the available code.
The Mellanox and Topspin folks along with some people from some of
the national labs are trying to start up a website called openib.org,
with data bases, email lists, etc. where people can submit code for
this "best of breed" stack and discuss it. As long as it is truly
open, the linux community is allowed to participate, and the code
is evaluated on it's technical merits, rather than one companies
personal
agenda, this forum might serve as a way for us to sort through this
without
taking every issue to lkml.
What are your thoughts on how we should proceed ?
"Woodruff, Robert J" <[email protected]> wrote:
>
> The Mellanox and Topspin folks along with some people from some of
> the national labs are trying to start up a website called openib.org,
> with data bases, email lists, etc. where people can submit code for
> this "best of breed" stack and discuss it. As long as it is truly
> open, the linux community is allowed to participate, and the code
> is evaluated on it's technical merits, rather than one companies
> personal
> agenda, this forum might serve as a way for us to sort through this
> without
> taking every issue to lkml.
That is, of course, an excellent approach.
But beware of being *too* disconnected from the [email protected]. We
don't want to get in the situation where you pop up with a couple of
person-years' worth of work and other kernel developers have major issues
with it. Please find a balance - some way of regularly checkpointing.
Also, beware of aiming for a finished product. We would *much* prefer that
a simple, minimal core, maybe with just a single device driver be merged
into the mainline kernel. The IBAL developers then proceed to enhance
that, sending regular updates. Every couple of weeks would suit.
That way everyone else can see the code evolving, and can help, and can
understand. And other people will fix your bugs for you, and update your
code as kernel-wide changes are implemented. And we all avoid nasty
surprises and extensive rework.
On Sat, Mar 13, 2004 at 02:07:13PM -0800, Woodruff, Robert J wrote:
>
> The Mellanox and Topspin folks along with some people from some of
> the national labs are trying to start up a website called openib.org,
> with data bases, email lists, etc. where people can submit code for
> this "best of breed" stack and discuss it. As long as it is truly
> open, the linux community is allowed to participate, and the code
> is evaluated on it's technical merits, rather than one companies
> personal agenda, this forum might serve as a way for us to sort
> through this without taking every issue to lkml.
>
> What are your thoughts on how we should proceed ?
I think you need to work with the openib.org people as they seem to
have:
- working code with support for a number of different devices
- developers with extensive kernel programming experience
working on cleaning up the code to fit properly into the
kernel tree.
- their code showing up in at least one distro which will expose
them to a much wider range of testing than Intel's project so
far has had.
So it seems that you really need to work with them if you wish to get
your code merged into theirs, as theirs already seems to be an almost
complete solution...
Good luck,
greg k-h