[Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility

David T. Lewis lewis at mail.msen.com
Fri Sep 11 20:15:00 UTC 2015


>
>
> On 11-09-2015, at 12:00 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> a) a plugin compiled for Spur may not work with V3 or vice verse.  The
>> issue is the header size of an object.  Some plugins, but not all, use
>> this define, and the header sizes between Spur and V3 are incompatible.
>>
>> b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't
>> work with 32-bit VMs. Period.
>
> At the very least we should make sure the version checking that was
> designed specifically to help handle this is actually getting used
> properly.

That's a good point, although it probably will not help with a many of
these cases. For example, with an interpreter VM the various permutations
of 32/64 bit host and 32/64 bit object memory are all compiled from a
single identical code base, but the plugins cannot be mixed among them. On
the other hand, it might be helpful for handling cases such as someone
trying to run a Cog plugin with a Spur VM, or trying to mix 32 bit plugins
with a 64 bit Spur VM.


> That ought to prevent crashes and help with providing some decent error
> messages.
>

In the case of mixing 32/64 bit compiled modules, the OS loader will not
let this happen, so the only issue is that the plugin (quite rightly) does
not load. But there might be other mixes of VM and plugin that could
result in a crash.

Dave

>>
>> Now there are platform-level packaging technologies, such as fat
>> binaries on Mac OS X, that allow one to construct plugins that contain
>> more than one binary.  But this is a lot of work to build and maintain.
>
> I suspect we could avoid that by using the versioning stuff to indicate
> which plugin file(s) the user/system fetches?
>
>
> As I (re)discovered this week, the unix vm  plugin/library loading is
> amazingly convoluted and looks in more directories than I think my Pi
> actually has. And it uses the name you give it prepended with ‘lib’ and
> appended with ‘.so’ and ‘dylib’, so searching for a plugin/lib involves an
> awful lot of checking and file testing. Looking in the
> platforms/unix/vm/sqUnixExternalPrims.c you can see what is being done.
> Note that ther eare two completely different approaches in that code and
> the Cog VM is using  (so far as I can tell) the NOT
> USE_SIMPLIFIED_PLUGIN_LOGIC branch.  The (somewhat old) copy of the plain
> interpreter VM equivalent I have around DOES use the simplified logic. We
> should probably clean that up...
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Fractured Idiom:- AMICUS PURIAE - Platonic friend
>
>




More information about the Vm-dev mailing list