[Vm-dev] OSProcess fork issue with Debian built VM

[K K Subbu]

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