[ofw] port_attr structure

[Fab Tillier]

Hi Jan,

 

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Jan Bottorff
Sent: Monday, February 19, 2007 11:58 PM



 

5)     You might want to consider updating the IBAL QUERY_INTERFACE
version number if ANY structure or error value changes in an
incompatible way. At least then, clients can detect a version problem,
instead of the system crashing when memory is corrupted. Generally in
the past, I believe this version number tended to only get updated if
the interface function pointer array was updated. Changing a parameter
structure doesn't change the source definition of the interface, but
very much can change the binary definition.

 

[ftillier] This was actually the intent of the interface version.  It
should have been incremented anytime the interface structure, the APIs,
return values, or the structures used by the APIs changed in any way
that would cause binary incompatibility.  If there was a change that
broke the binary compatibility but didn't increment the interface
version, that change was incomplete.  This design came from the fact
that the IBAL interface wasn't designed with versioning in mind.  This
caused crashes when only some drivers were updated and I wanted to at
least get an error when incompatible versions were used.  There are
nicer ways to handle versioning of interfaces, but the current method
should work if done properly.

 

It should be feasible to support past interfaces - the thing to figure
out is the policy for how long a previous interface is maintained and
supported.  It would be great to have you put some sort of marker in the
SVN repository indicating that you have a dependency - it would make it
easier for people considering changing the interface to scope the impact
of a change.  Note that I'm not suggesting publishing your actual code,
just a place holder with contact information so that you can be
contacted proactively as design changes are considered.

 

It may make sense to add new functions and structures (for example, a
port info query function) rather than change existing ones.  Then
supporting multiple interface versions becomes a lot simpler as only the
interface definition changes, with new versions extending previous
versions.  Old functions can even be marked deprecated (see the
deprecated pragma) to indicate that support for a function is going away
in a future release.

 

-Fab 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20070220/79ab50ff/attachment.html>