On Tue, 19 Oct 2010 18:00:51 -0700 "Hefty, Sean" <sean.he...@intel.com> 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 wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
