[ofw] [PATCH] Bump up CI and AL interface version numbers

[Anatoly Greenblatt]

I think what Fab means is illustrated by different example:
 
revision 987
#definve desc_version 1
struct desc {
  int version;
  void* vaddr;
  int size;
};
 
revision 1045
#define desc_version 2
struct desc {
  int version;
  void* paddr;
  void* vaddr;
  int size;
};
 
 
application code:
 
if (desc->version == desc_version == 1)
 ...
else
 ...
 
The version indicates a change in struct definition.
 
Anatoly.

________________________________

From: Hefty, Sean [mailto:sean.hefty at intel.com]
Sent: Tue 8/26/2008 11:23 PM
To: Anatoly Greenblatt; Fab Tillier; Tzachi Dar; ofw at lists.openfabrics.org
Subject: RE: [ofw] [PATCH] Bump up CI and AL interface version numbers



>You're right - all libraries must support all kernel interfaces. But we also
>need a way to differentiate between variants of same interface. There could be
>a situation where newer library works with older driver (or viese versa) and
>the order of elements in some struct definition has changed between versions.
>That is why interface version number should be increased to let application
>recognize the change..

I never said not to increase the interface version.  Just that the version number should be bumped once for a given set of changes, and tied to releases, not development.  Otherwise, we have version 3 followed by version 12 followed by version 29, just because of some arbitrary check-in decisions.

Consider this differently.  Suppose that you're creating a new API.  You implement ib_open_al() and ib_close_al(), commit the changes, and call it API 1.  You add ib_open_ca() and ib_close_ca() - API 2.  Ib_alloc_pd(), ib_close_pd() - API 3... and so on until you finally release the API as version 48.  Checking code into source control != an API version.

- Sean