Re: [Valgrind-developers] Matching core and skin versions

[Nicholas N. <nj...@ca...>]

On 29 Oct 2002, Jeremy Fitzhardinge wrote:

> I think a better scheme would be to have the core export a preprocessor
> define called something like VG_IF_VERSION.  The skins would then simply
> do:
>
> 	details->core_interface = VG_IF_VERSION;
>
> If the core makes an incompatible change to its skin interface, then
> increment the IF_VERSION.  You could use a string in X.Y format, where
> changes in X are completely incompatible, but Y indicates a backwards
> compatible change.
>
> This way the association between skin binary and core is checked by the
> compiler and then built into the skin automatically.

Hmm, I like this.  Decoupling the interface version and the Valgrind
version is a v. good idea, as is the X vs. Y version changes compared to
the set of compatible versions.  It also means the skin writer doesn't
need to worry about tracking core versions because it's done
automatically.

> So long as the interface doesn't expose any structures which can change
> shape, this should work well.

Not sure if I understand this fully... only problem I can think of is that
the `details' struct changed so that the `core_interface' field was in a
different place.  The `details' struct is the first argument to
VG_(pre_clo_init) so changing the other structs shouldn't matter, I think.
And if I make `core_interface' the first field in `details' that should
even work if more fields are added to the end of `details' later on?

> If you want to get fancy

nope :)

----

BTW, my understanding of what constitutes a backward (in)compatible change
is hazy with shared objects... here's what I'm guessing is backward
compatible:

  add a local  function to core:  yes
  add a global function to core:  yes

  change a global function's args in core:  no
  change a data structure (eg. struct) seen by skins: no

There are sure to be other things I haven't thought of here.

It seems like there are two levels of incompatibility, too:

  a. changes which require a skin to be recompiled
  b. changes which require a skin's code to be changed

An example of (a) would be adding a new (optional) field to the `needs'
struct.
An example of (a) would be adding a new (compulsory) field to the
`details' struct.

Am I on the right track?  Any other comments, etc?  Thanks.


N