On Wed, Jun 05, 2013 at 05:01:37PM +0000, Jeff Squyres (jsquyres) wrote: > On Jun 5, 2013, at 9:46 AM, Jason Gunthorpe <[email protected]> > wrote: > > > No, this too big of an ABI break, and silent at that.. > > > > The IBA values have to continue to be accepted and exported in all > > cases so the ABI stays the same, which is what I thought was agreed > > on?? > > Can this go to a libibverbs 2.0, where it would be palatable to have > an ABI break?
The concept of a libibverbs 2.0 has been NAK's by pretty much everyone involved. This is why we are suffering with the complex extension mechanism. The mixed approach that was brought up, where values like 1500 were passed as 1500, and values like 1024 were passed as 3 seemed doable to me. Did you see a problem with it for your use? Thoughts: - 1024 and 3 both mean 1024, the library must accept both values, it should only ever return 3 though. - 1500/etc means 1500, the libray can return that. - Make a ibv_from/to_mtu inline function to translate from bytes to the encoded MTU value. - Switch ibv_mtu from a enum to a typedef int ibv_mtu Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
