[ofa-general] Re: How to tell what OFED rev a distro derived IB modules?

[Chris Worley]

On Mon, Apr 27, 2009 at 5:03 AM, Bart Van Assche
<bart.vanassche at gmail.com> wrote:
> On Mon, Apr 27, 2009 at 8:27 AM, Jack Morgenstein
> <jackm at dev.mellanox.co.il> wrote:
>> The OFED distributions may contain features that the mainstream kernels and libraries do not support.
>> These features frequently require changes in the Infiniband kernel modules.  Such changes are in the form
>> of kernel patches which are applied to the base mainstream kernel on which the OFED release is based.
>> A lag between the mainstream kernel and the OFED kernel is unavoidable, since the new features are first
>> released in the OFED distributions -- and later, gradually (and hopefully), these features make there way
>> into the upstream kernel.
>
> I don't doubt that there is a good reason why new features go in the
> OFED distribution first and later in the mainstream Linux kernel.

My opinion is: IB is still just too bleeding edge, even for the
vanilla Linux kernel.

Maybe "Upstream First" is the measure of IB achieving stability.

SRP (specifically the SCST target code) is my first case in using IB
where I've not been able to start with the latest OFED (or IBGD)
stable release, as OFED is unsupported by the SRP target code, and had
to start with a distro's IB version to get a working SRP target (of
which Ubuntu 8.10 provided the only stable SRP target distro for my
configuration).

Chris
> But
> it's not clear to me why this process has been chosen. There is wide
> agreement in the Linux kernel community that new kernel code should go
> first in the mainstream Linux kernel and from there to the various
> Linux distributions, and not the other way around. This is called the
> "upstream first" policy. One of the most highly regarded kernel
> maintainers (James Bottomley) wrote the following about the "upstream
> first" policy:
>
> * Major distributions have agreed not to incorporate features or
> drivers unless they are on “upstream track”
> for the vanilla Linux Kernel
>  - Obviously there’s some flexibility in interpretation of this for
> their best customers
> * Primary reason is that it keeps the distribution kernel code and the
> vanilla kernel code as close as possible, so
>  - Maintenance is reduced: the distro can file a bug with the
> upstream maintainer if there’s a problem.
>  - Testing is enhanced: users of all distributions are testing the same code
>  - Code Review burden is greatly reduced: Can rely on upstream
> maintainers to review and accept.
>
> More information about the "upstream first" policy can be found here:
> * James Bottomley, Hacking the Linux Kernel for Fun and Profit, 5
> April 2008, http://www.flourishconf.com/flourish2008/images/downloads/flourish2008-jamesbottomley-hackingthelinuxkernel.pdf.
> * Jonathan Corbet, A Guide to the Linux Kernel Development Process,
> 2008, http://lwn.net/talks/lfeu2008/devproc/index.html.
>
> Bart.
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>