[Vm-dev] Stupidifying FFI/library loading mechanism

[Luc Fabresse]

2011/5/26 Igor Stasenko <siguctua at gmail.com>

>
> On 26 May 2011 14:16, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > I am not sure if it applies to your proposal here, but just in
> > case I want to mention one note of caution. The #primLoadModule
> > that was discussed previously in the "Sandbox" thread will not
> > work on a 64-bit platform, for the same reason that FFI does not
> > work on a 64-bit platform.
> >
> Sorry, i din't followed that issue (cant remember). The reason because
> of mixing 32/64bit libraries, or something else?
>
> The primitive you mentioning reusing the same routine to load external
> module
> as VM internally for primitives do. So, it is step in right direction
> (explicitly instruct VM to load modules),
> but more work needs to be done.
>
> Now imagine that you have a primitives:
>
> loadInternalModule: moduleName
> loadExternalModule: moduleName path: pathToModuleLibrary
>
> and by analogy, for FFI:
>
> loadExternalLibrary: pathToExternalLibrary
>
> and in case of failure, these prims could then give you an extended
> response:
>  - module already loaded
>  - internal module not exists
>  - external library file not found
>  - external library file found but cannot be loaded (not a library,
> mix 64/32bit mode etc)
>  - module loaded but failed to initialize
> .. etc
>
> Then you can easily diagnose the problems per each attempt to load some
> library.
> But not like today.. if you telling to load module named 'GL' , VM
> tries all different combinations
> like
> libGL.so GL.so
> libGL.dynlib
> multiplied on various crazy locations in file system..
>
> Is it only me who thinks that, this looks like shooting blindly into
> the sky hoping there are enough ducks flying so you can hit one?
>
> Also, if you explicitly control the module loading then you can also
> control which module takes priority
> - internal or external one.
>
> if you know, today's VMs first attempting to load external library
> with given name, and only then internal plugins.
>
> Apparently, if you wanna play games in sandbox, you'd be willing to
> change a priority or even do not attempt to use
> any external modules at all.
>

+1
paths used to look for external libraries (FFI or plugins) should be simpler
and documented. I am always looking into log to know why it failed.
IMO, it should also be easy to share external libs between VMs.
I already share some libraries but it requires to discover some strange
paths.

#Luc



>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110526/9fc609cc/attachment.htm