[ofw] API breakage in trunk

[Leonid Keller]

 > > I don't see any reason why ib_ca_attr_t can't just be extended ...
One can do it.
It doesn't break backward compatability, so old applications will work well with new kernel (i.e. with extended ib_ca_attr_t).
But new applications, running against old kernel,  may crash. 


> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Monday, February 22, 2010 6:17 PM
> To: Leonid Keller; 'James Yang'; Tzachi Dar; ofw_list
> Subject: RE: [ofw] API breakage in trunk
> 
> >We can now add new fields at the end of the structure for 
> version = 1, 
> >like
> >
> >	// for LLE
> >	enum rdma_transport_type[MAX_PORT_NUM]	transport;
> >
> >	// for vendor specific info
> >	enum vendor_info_type		vendor_info;
> >	union {
> >		uplink_info_t		mlnx_vendor_info;
> // for
> >Mellanox
> >	};
> >
> >It doesn't break the backward compability as far as I see.
> 
> Keep in mind that existing applications do not check or set 
> this field.  So it's not clear how an app uses it.
> 
> >What do you think ?
> >
> >Implementation note:
> > The structure ib_ca_attr_t contains a variable part, 
> consisting of two 
> >arrays (page_sizes and port_attrs).
> > Their start is shown by pointers p_page_size and p_port_attr.
> > In version 1 these arrays will be placed *after* new fields and the 
> >pointers will be appropriately adjusted.
> 
> I don't see any reason why ib_ca_attr_t can't just be 
> extended, with all new fields at the end of the structure.  
> It's the per port data that has issues.
> 
> For the kernel, I don't see problems with any of the changes, 
> but breaking user space apps is different.  Also, winverbs 
> has versioning built into its interfaces, so exposing this 
> sort of change through that interface is easier to manage, if 
> you're willing to start deprecating other interfaces.
> 
>