design choices for a loadable module interface

[Russ Allbery]

Nicolas Williams <Nicolas.Williams at oracle.com> writes:

> That just means that all plugins export functions with the same names,
> as opposed to having to prefix each plugin's exported functions' names
> with a disambiguator, such as the plugin's name.

Oh, okay.  I certainly agree with that.

> HOWEVER, just because there is one thing that the linker/loader will not
> do for us does not mean we should throw the baby out with the bath water
> and effectively duplicate other linker/loader functionality.

Could you be more specific about exactly what functionality you see the
vtable approach as duplicating?  I assume you mean something more than
just writing the struct definition of the vtable, since that's trivial.

>> With either the vtable or the function approach, you have to rename the
>> symbols whenever the signature changes.  With the vtable approach, you

> Not so.  You can deprecate old ones and add new ones.  No renames
> needed.

That's what I meant by "rename."  That's what I assumed we would do in a
rename.  The point is that the current recommended API uses a different
name than the previous one so that backward-incompatible changes can be
made.

> If you decide to never make backwards-incompatible changes to function
> signatures and semantics then you there is no need to keep track of
> anything more with one scheme or the other.

I believe the chances of successfully holding to such a decision are zero.
There will be backwards-incompatible changes to function signatures and
semantics.  The framework should plan for them from the start.

> (1) and (2) really are equivalent, except that (2) requires more work on
> the part of plugin authors than (1).

Speaking as a plugin author, the amount of additional work (2) requires is
not sufficient to warrant calling it additional work (although of course
just providing a public data symbol is even easier).  It's a trivial
function that one can write in five minutes.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>