Posted by K K Subbu on Jun 02, 2017; 10:28am
URL: https://forum.world.st/OSProcess-fork-issue-with-Debian-built-VM-tp4947326p4948943.html

 
On Friday 02 June 2017 10:10 AM, Esteban Lorenzano wrote:
> I’m sorry, but all of this is a mess.
> Why not simply require that all plugins that are part of the VM lives in
> the same place?
>
> In an ideal world, that unified place would be VMMaker repository
> itself, but if not… why not a /VMPlugins project?

+1. I would go further and propose that plugins, other than those which
are integral to VM[1], be moved into separate projects and built in
their own tree with no references to vm source paths. They should be
free to organize their platform-specific and platform-independent code
and makefiles.

I suppose this requires factoring essential VM functions into libstvm
(runtime+header files) and then generate integral plugins using this
library. The main VM can then parse options, open image file and invoke
the interpreter main loop. It could also dynamically load a matching
interpreter lib for the image instead of bailing out with an unknown
image error.

To start with, libstvm components can be exported into
$BUILD/lib/libstvm.so and $BUILD/lib/include/sq.h ...

Has anyone tried this before?

[1] like vm-display-null, vm-sound-null, fileplugin, osprocess etc.

Regards .. Subbu