<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 9, 2018 at 5:53 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 10/04/2018 10:40, Gedare Bloom wrote:<br>
> On Mon, Apr 9, 2018 at 4:17 PM, Russell Haley <<a href="mailto:russ.haley@gmail.com">russ.haley@gmail.com</a><br>
</span><span class="gmail-">> <mailto:<a href="mailto:russ.haley@gmail.com">russ.haley@gmail.com</a>>> wrote:<br>
>             I'd like to start with getting other Lua scripts running. My goal is<br>
>             to load a library called penlight that's a few dozens of files. Is<br>
>             there a utility for creating and loading resources? I'll also look<br>
>             at compiling the files using the luac compiler, but that's outside<br>
>             of rtems.<br>
><br>
> No worries. There is evolving support (pretty mature by now) for dynamically<br>
> loading object code, if that is what you mean: the Runtime Loader (RTL).  I<br>
> don't have any experience with it though. Chris Johns is the expert on that topic.<br>
>  <br>
<br>
</span>The support is based around the standard calls 'dlopen' etc. You can load ELF<br>
object files. You do need a symbol table in the kernel and a simple makefile<br>
recipe can be found in the testsuite which works on the sparc simulator:<br>
<br>
<a href="https://git.rtems.org/rtems/tree/testsuites/libtests/Makefile.am#n319" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/<wbr>tree/testsuites/libtests/<wbr>Makefile.am#n319</a><br>
<br>
 (search for TEST_dl01 in the Makefile.am if the line has moved)<br>
<br>
Note, the erc32 sim does not have access to a host's file system so you will<br>
need to package the object files into a tar file just as the test does.<br></blockquote><div>Hi Chris, good to hear from you. Yes, the non-filesystem is what I'm trying to deal with. Lua can run as C or as Lua scripts. The dlopen support is excellent and I'll look into that when I start loading C. There are many fine Lua wrappers for some of the best C tools. Since, I'm trying to load lua scripts, the tar package sounds like what I need to look at first.</div><div><br></div><div>Lua scripts can be loaded as a 'string' buffer (char array), or from a file. Either of those methods can load a text file or a Lua VM binary. Using binary is apparently faster to load, but must be compiled for the same architecture. The run speed is the same.  </div><div><br></div><div>A simple Lua script to load a second module would look like this:</div><div><br></div><div>    local my_lib = require('mylib.init')</div><div>    local new_val = my_lib.dosomething()<br></div><div><br></div><div>The require() function loads the file from a filesystem based on the package.path string. On my windows box, it looks like this:</div><div><br></div><div>.\?.lua;C:\Program Files (x86)\LuaRocks\lua\?.lua;C:\Program Files (x86)\LuaRocks\lua\?\init.lua;C:\Program Files (x86)\LuaRocks\?.lua;C:\Users\russh\scripts\?\init.lua;C:\Users\russh\scripts\?.lua;C:\Users\russh;C:\Program Files (x86)\WinLua\Lua\5.3\bin\?53.dll;<br></div><div><br></div><div>So, the require('mylib.init') would get translated so the '.' becomes the path separator on the filesystem, and any '?' in the package.path is replaced with the package name, eventually landing on C:\Users\russh\scripts\mylib\init.lua. Let's see how that translates to RTEMS... </div><div><br></div><div>Thanks!</div><div>Russ</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>