> > 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:[email protected]] > 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. > > _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
