Re: ib mad definitions

[Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org>]

On Tue, 19 Oct 2010 18:00:51 -0700
"Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> > Can we at least agree on the usage of these structures first? Are the
> > constants going to be in host or network byte order?
> 
> I was simply suggesting to 'move' some of the existing structures and defines.
> 
> > Are you going to make something like the kernel where there is a
> > native structure and pack/unpack function set?
> 
> This would not be my preference.
> 
> > Something macro-based like foo = GET_MEMBER(*pr,preference)
> > 
> > Network byte order casting structures?
> > 
> > Host byte order casting structures? (my favorite)
> > 
> > bitfields?
> 
> again - not my preference
> 
> > Ira, I think the cleanest answer is that OSM keeps its type file, and
> > umad gets a new one that is cleaner, more capable and probably
> > incompatible. I'd hate to see us stick to the OSM scheme for umad just
> > for code compatability.
> 
> Whatever is done must fit within the windows development framework that we use.

I am all for "cleaner, more capable..." but why incompatible?  If we want to
start fresh and then convert OpenSM later, fine.  But _don't_ forget to go
back and convert OpenSM, because if you leave ib_types.h out there someone is
going to use it and we are back to where we started...  :-(  Same for ibmad,
when these definitions become available in umad, mad can be simplified.

What I would like right now is to get the definitions in 1 place!

Right now there are 3 headers I find path record in.

libibverbs: sa.h
libibmad: mad.h
opensm: ib_types.h


Node type is defined in:

libibverbs: verbs.h
opensm: ib_types.h
libibmad: mad.h

I could go on.

What Sean is offering to do is move ib_types to umad.  From there I can use
those definitions in mad (thus removing them from mad and consolidating at
least 2 of the 3 above).  Perhaps use them in ibverbs as well?  As a first
step I think we should take Sean up on his offer to start cleaning things up.
But we have to remove stuff as we go or we will just be defining yet another
place to look for these.  After this we can look at making things cleaner
(perhaps even combining mad and umad, and including some of the ideas you have
above).  As Sean said in another email, after this change; including
"ib_types.h" will be the same for anyone using it.  The exception is that we
have simplified the code.  I think this is a win-win with minimal work.

Ira

-- 
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html