I agree that SM (OpenSM) doesn't need CM definitions. ib_types.h was for convenience of other apps and having all the definitions in one place. It includes other definitions for other classes also unused by OpenSM. Once libibsa is present and supports (at least) all the SA attributes that OpenSM does, we could then talk about moving this over. However, at that point, things will be quite different between Linux and Windows versions of OpenSM unless Windows adopted more of what going on in Linux. -- Hal
________________________________ From: Sean Hefty [mailto:[EMAIL PROTECTED] Sent: Mon 8/14/2006 7:44 PM To: Hal Rosenstock Cc: Michael S. Tsirkin; [email protected] Subject: Re: [openib-general] Conflicting typedefs for "ib_gid_t" Hal Rosenstock wrote: > Do you have a proposal for how to get to where you think this needs to be ? > Have you looked at this ? I think defining include files similar to what we have for the kernel make sense. The problem is more complex than what definitions an application gets from which include file. The data in these structures are also exchanged between userspace and the kernel. For example, there's an sa.h file as part of libibverbs, since it marshals parameters from kernel to userspace. Wire structure definitions ended up working well for me for user to kernel transitions. > I think you are proposing OpenSM include verbs.h. I think that's only part of > what would need to be done (and has some other side effects). I would also have definitions in a libibsa and libibcm. The relevant CM definitions are there. (I don't see a need to expose most of the CM wire definition outside of the kernel.) I can't think of a reason why OpenSM would need any CM definitions, so I would remove those from from any OpenSM include files. SA attribute structures are also needed by libibsa, but since it seems overkill to include OpenSM on all nodes, I would define the SA attribute structures as part of libibsa, and let OpenSM use its include files. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
