On Thu, 2004-10-28 at 01:29, Roland Dreier wrote:
> I would be fine with consolidating work onto the roland-merge branch
> and pushing core/mad changes through you and Hal, if that's what the
> consensus is.
> Or we could copy roland-merge to a new branch with a different name
> and work there.
A
On Thu, 2004-10-28 at 02:06, Sean Hefty wrote:
> Either is fine. I'd just like to get to a single branch. Renaming
> roland-merge may make it easier for people to locate the correct code.
Not sure what you mean by "correct code" in the statement above.
-- Hal
On Wed, Oct 27, 2004 at 10:29:02PM -0700, Roland Dreier wrote:
> Or we could copy roland-merge to a new branch with a different name
> and work there.
I'd prefer this *after* openib.org blesses the new name.
Otherwise calling it roland_merge is fine with me.
grant
On Wed, 27 Oct 2004 22:29:02 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Sean> I didn't realize that you had taken a copy of the current
> Sean> mad code. Is there anything in the openib-candidate branch
> Sean> that isn't in your branch? Does it make sense to just
> Sean> u
Sean> I didn't realize that you had taken a copy of the current
Sean> mad code. Is there anything in the openib-candidate branch
Sean> that isn't in your branch? Does it make sense to just
Sean> update the code in the roland-merge branch?
I've got everything up to r1080 in my bra
On Wed, 2004-10-27 at 16:35, Roland Dreier wrote:
> OK, I'm going to go ahead and rename ib_mad.c -> mad.c, ib_agent.c ->
> agent.c etc. (This also makes it possible to build a module named
> ib_mad.o, which I think makes more sense than ib_al.o, from multiple
> sources).
>
> I can continue to me
On Wed, 27 Oct 2004 13:35:22 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> OK, I'm going to go ahead and rename ib_mad.c -> mad.c, ib_agent.c ->
> agent.c etc. (This also makes it possible to build a module named
> ib_mad.o, which I think makes more sense than ib_al.o, from multiple
> sources)
OK, I'm going to go ahead and rename ib_mad.c -> mad.c, ib_agent.c ->
agent.c etc. (This also makes it possible to build a module named
ib_mad.o, which I think makes more sense than ib_al.o, from multiple
sources).
I can continue to merge by hand but it might make sense to make the
same change on
Grant> Up to you (or whoever maintains the code). Some drivers
Grant> that have their own subdir keep the prefixes. e1000 and
Grant> sym2 drivers are the counter examples I had in mind.
Good point... well, I'm getting sick of typing ib_ :)
Also I'd argue that the e1000_ or sym_ pref
On Mon, 2004-10-25 at 13:57, Roland Dreier wrote:
> I have a couple of questions/suggestions about how we want to arrange
> the code for kernel inclusion:
>
> 1. Does it make sense to remove the ib_ prefixes on .c files in
>drivers/infiniband/core? After all, someone looking in
>
By the way, here's what the diff to the code to combine ib_mad and
ib_agent looks like (appropriate Makefile changes are also needed).
Index: linux-kernel/infiniband/core/ib_agent.c
===
--- linux-kernel.orig/infiniband/core/ib_agent.c
On Mon, Oct 25, 2004 at 10:57:33AM -0700, Roland Dreier wrote:
> I have a couple of questions/suggestions about how we want to arrange
> the code for kernel inclusion:
>
> 1. Does it make sense to remove the ib_ prefixes on .c files in
>drivers/infiniband/core?
Up to you (or whoever m
I have a couple of questions/suggestions about how we want to arrange
the code for kernel inclusion:
1. Does it make sense to remove the ib_ prefixes on .c files in
drivers/infiniband/core? After all, someone looking in
drivers/infiniband should realize they're looking at IB sou
13 matches
Mail list logo
