Lua bindings

[jheretic]

We need Lua bindings, amongst other things, to allow LuCI to more cleanly interface with libcommotion.

[areynold]

Could you be more specific about the scope of this task? Is it enough just to bind the uci functions?

Edit: Never mind. I think I got the direction wrong. Is this more like the shell bindings for openwrt, so access to commotiond functions in lua?

[seamustuohy]

Yea, this would be a Lua library that is directly tied to the commotiond C code. Essentially the same way that lua.model.uci has some functions that are just C code that can be imported when calling Lua code. This would make it so LuCI would not have to fork out a new shell to call Commotion functions, but could directly interface with the C backend through a lua/c library in the existing lua process.

https://www.youtube.com/watch?v=IkJqKOb0ZhY&feature=kp

[legontanon]

Once I got Lua into Wireshark... If you want I'll be happy to get Lua into commotion ... I would need a description of what's to be wrapped and some pointers on where to work to get me started.

[jheretic]

Hi @legontanon , that would be really great! The only API that exists right now is the C client API. Right now, this is essentially just a barebones API for connecting to a running commotion daemon instance, sending it requests, and receiving responses. You can find the API in src/commotion.h, and the doxygen documentation at https://commotionwireless.net/developer/api/commotiond/html/commotion_8h.html. That might be a good starting point.

Eventually, we'd like to add support for the language bindings directly. For instance, the commotion daemon supports a number of different commands, some of which are built in and some of which are loaded from plugins. In order to call any of them right now, you would use the client API to marshal the command and its arguments, and then receive the result back. However, a binding in a language like lua could actually directly have functions for things like getting configuration values, signing keys, etc. Those functions would then use the C client API on the backend.

Additionally, we're also working on a 'core API,' which would involve splitting out the libcommotion 'standard library' from the daemon, and consolidating its headers into a structured API for using it's functionality, like network abstraction and JSON serialization/deserialization. It's a little bit further out, so it's not as certain what that would look like.

[legontanon]

I'm working a quick and dirty wrapper around co_obj_t and family... Just to get started.. Few obserbations:

I find unconfortable that co_obj_t's "extended subtypes" have a different struct wrapper aroud them (with common elements)...
I was thinking is wrapping all extension subtypes of co_obj_t in

typedef struct co_extobj_t {
co_obj_t _header;
uint8_t _exttype;
uint8_t _len;
} co_extobj_t;

and then refactor all subtypes for it:
i.e.
struct co_iface_t {
co_extobj_t _header;
...
} attribute((packed));

Nothing changes in the way data is layout, so it shouldn't have any impact, but this allows for easier constructs dealing generically with extended objects.

Then to the main issue:
As with Wireshark an issue here is how to deal with the different lifespan of objects in the environment and in the language, so that garbage-collection on either side of the thing does not leave broken pointers on the other side.

I haven't studied the issue yet as currently I'm more involved with finding the "patterns" for the macros for adding easily the API to Lua .

My question is obj type _ptr already thought for ?
It be so nice to use it for keeping references to an object, so that we can tell Lua the pointer is invalid when the other side deletes it.

\Lego

[legontanon]

I'm going with a wrapper for the entire API...
forked, the (so far incomplete) work is here...
https://github.com/legontanon/commotiond/blob/master/src/luawrap.c

are there plans to use the object flags?
can I use 2 bits of them for managing Lua garbage collection?
one for whether is managed by lua, another for whether is floating or not.

[jheretic]

Hi @legontanon, apologies for the delay replying, my laptop died last week and caused me to get a bit behind. There are plans to use the object flags; I'm currently working on some cleanup work that will use a couple of the flags to define whether or not a given object is tied into malloc() for garbage collection, and whether they have a custom serialization function. However, that work is not yet well-defined and will only use the first couple of flags; you can feel free to use 2 of the bits for managing the lua garbage collection.

[legontanon]

@jheretic:
I changed my path while walking... Lots of mechanical work got me bored and error prone... so...
Right now I'm into writing a "good" Lua api code generator ( one that's light and versatile, the ones I've tested in the past aren't good for one reason(usu. slow code) or the other(lack of versatility) ), simply because I know overall it will be cheaper to write and test the code generator, and then use it for doing the whole thing, reducing the overall times of debugging compared with those of non generated code. https://github.com/legontanon/commotiond/tree/master/src/extern/luaqwrap

In the meanwhile we probably want to define how the flags are to be used in regards of GC, because some of what I got to do with the flags for Lua is exactly knowing when to invoke a destructor and how and when just to purge the object from Lua. So for now I'll leave placeholders for the garbage collection and leave their implementation for later.

[dismantl]

@legontanon: What is the progress of your Lua API code generator? I'm looking into options to create Lua bindings for the Commotion Service Manager, and would be interested in trying LuaQWrap if it's working.