Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-01 Thread Or Gerlitz

Ralph Campbell wrote:

Vlad, please pull from
  
Ralph, Tziporet, any reason not to wait till this core patch is accepted 
to the mainline kernel?


Or.


commit 840bbefeda26d21bffae6b7cdc88e981fcfb0a45
Author: Ralph Campbell (QLogic) 
Date:   Mon Nov 30 14:09:34 2009 -0800

IB/core: allow HCAs to create IB port sysfs files
This patch adds a new function to sysfs.c so that HCAs can
create files in /sys/class/infiniband//ports//.
There is no need for an unregister function since the kobject
reference will go to zero when ib_unregister_device() is called.

Signed-off-by: Ralph Campbell 


  


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-02 Thread Ralph Campbell
No reason not to wait unless it goes beyond OFED-1.5
ship date. I don't think waiting until the last minute
is a good idea. Note that this interface is between ib_qib
and ib_core so if the final form accepted upstream is
different, it can be changed without impact since the kernel
modules are all compiled at the same time. I don't think
this is likely to happen since it fixes Roland's original
concern with exporting struct ib_port.

On Tue, 2009-12-01 at 01:48 -0800, Or Gerlitz wrote:
> Ralph Campbell wrote:
> > Vlad, please pull from
> >   
> Ralph, Tziporet, any reason not to wait till this core patch is accepted 
> to the mainline kernel?
> 
> Or.
> 
> > commit 840bbefeda26d21bffae6b7cdc88e981fcfb0a45
> > Author: Ralph Campbell (QLogic) 
> > Date:   Mon Nov 30 14:09:34 2009 -0800
> >
> > IB/core: allow HCAs to create IB port sysfs files
> > This patch adds a new function to sysfs.c so that HCAs can
> > create files in /sys/class/infiniband//ports//.
> > There is no need for an unregister function since the kobject
> > reference will go to zero when ib_unregister_device() is called.
> > 
> > Signed-off-by: Ralph Campbell 
> >
> >   
> 

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-02 Thread Or Gerlitz

Ralph Campbell wrote:

I don't think this is likely to happen since it fixes Roland's original concern 
with exporting struct ib_port
whatever, still its a patch to the core that adds new API, etc, needs to 
pass the maintainer acceptance. Its been two weeks since you sent v2, so 
a kindly reminder to Roland might do the job, try it.


Or.

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-08 Thread Or Gerlitz
Or Gerlitz  wrote:

> Tziporet, any reason not to wait till this core patch is accepted to the
> mainline kernel?
>
Vlad, Tziporet, any reason not to address my question, silently ignore my
email and just pull this without acking as you usually do, what's the story
behind that?!

Or.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

RE: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-08 Thread Tziporet Koren
Yes - we are going for RC4 this week and GA on 21-Dec, so we need all
changes now so we can make sure the new commits are passing install in
all OSes we support

 

Tziporet

 

From: Or Gerlitz [mailto:or.gerl...@gmail.com] 
Sent: Tuesday, December 08, 2009 9:14 PM
To: Tziporet Koren; Vladimir Sokolovsky
Cc: Ralph Campbell; ewg@lists.openfabrics.org
Subject: Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

 

Or Gerlitz  wrote:

Tziporet, any reason not to wait till this core patch is accepted to the
mainline kernel?

Vlad, Tziporet, any reason not to address my question, silently ignore
my email and just pull this without acking as you usually do, what's the
story behind that?!

 

Or.

 

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-08 Thread Or Gerlitz
Tziporet Koren  wrote:
> Yes – we are going for RC4 this week and GA on 21-Dec, so we need all changes 
> now so
> we can make sure the new commits are passing install in all OSes we support

whatever, why not replying on my note saying this? you (vlad) are
acking every pull request with the exception of this one on which
someone had a comment, what's the reasoning behind this working mode?
why you violate the Sonoma's 2007/2008/2009 decisions not to merge
into a release patches to the core which weren't accepted yet into the
mainline kernel? either defer the release or bring into some table
(e.g email)

Or.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-08 Thread Betsy Zeller
Or - the agreement in Sonoma was that anything submitted to OFED should
also be in the process of going into the kernel. Because Roland can't
always respond in the time frame required to match the OFED schedule, we
explicitly said it didn't have to be accepted. If it turns out that
there is some major issue with the change in question ( which has been
submitted upstream), we'll respond to that. But I also don't want to
either hold up the release, or redo an entire set of patches because of
this one (relatively small) change.

On Tue, 2009-12-08 at 12:09 -0800, Or Gerlitz wrote:
> Tziporet Koren  wrote:
> > Yes – we are going for RC4 this week and GA on 21-Dec, so we need all 
> > changes now so
> > we can make sure the new commits are passing install in all OSes we support
> 
> whatever, why not replying on my note saying this? you (vlad) are
> acking every pull request with the exception of this one on which
> someone had a comment, what's the reasoning behind this working mode?
> why you violate the Sonoma's 2007/2008/2009 decisions not to merge
> into a release patches to the core which weren't accepted yet into the
> mainline kernel? either defer the release or bring into some table
> (e.g email)
> 
> Or.
> ___
> ewg mailing list
> ewg@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-08 Thread Or Gerlitz
Betsy Zeller wrote:
> the agreement in Sonoma was that anything submitted to OFED should
> also be in the process of going into the kernel. 

what prevents you from sending a reminder to Roland?

Or.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes

2009-12-09 Thread Roland Dreier

 > Or - the agreement in Sonoma was that anything submitted to OFED should
 > also be in the process of going into the kernel. Because Roland can't
 > always respond in the time frame required to match the OFED schedule, we
 > explicitly said it didn't have to be accepted. If it turns out that
 > there is some major issue with the change in question ( which has been
 > submitted upstream), we'll respond to that. But I also don't want to
 > either hold up the release, or redo an entire set of patches because of
 > this one (relatively small) change.


This is to a large degree hogwash.  The entire qib driver was shipped in
an OFED release long before it was even submitted upstream for the first
time.  So this change in particular is not a big deal but the
development methodology of completely throwing away the upstream ipath
driver and shipping a new codebase (of 50,000+ lines of code!) as part
of OFED seems pretty broken to me.

To be honest I think the qib driver is a symptom of a pretty big
problem.  Looking at the git logs, I see that we merged the ipath driver
around March 2006, and the last patch from qlogic in December 2008.  So
it took you guys about 2.5 years to decide that your first driver was an
unmaintainable mess and had to be thrown away.

I see many signs of the same philosophy of "our needs don't match the
existing kernel facilities perfectly, so let's hack around it or
reimplement it in device-specific driver in an ugly way rather than
working outside our driver to fix the interface" in qib.  Given the
track record of quickly giving up on code as unmaintainable, I'm hoping
we can at least get the qib driver into shape where the community can
continue to keep things together if you guys give up on it.


 - R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg