Re: Moore-FSM on OpenWRT

[Justin Cormack <justin@...>]

On Sun, Sep 2, 2012 at 11:26 AM, Jan Lühr <lua@stephan.homeunix.net> wrote:
> Hello folks,
>
> I'm trying to implement an FSM in Lua to model the state of a wireless router. The system is running OpenWRT, so using lua seems to be a reasonable choice.
> Since I'm new to lua (I actually looked a lua yeasterday for the first time), I've some questions :-)
>
> The FSM I'm trying build is splitted into two files:
> -> One is used for defining the FSM. The definition itself is one big lua table. I've come up with this: http://pastebin.com/ypUuUmpJ
> -> The other file implements a set_signal(signal, value) function (implementation outstanding).
>
> Since the definition of the FSM should look well ("DSL-stylish"), this separation seem to be a valid choice.
>
> However, I'm stucked with the set_signal(signal, value) function. The function should:
> -> Increment counters (if defined for a given signal)
> -> Iterate through all transitions, executing each guard.
> -> If one guard evaluates to true:
> -> Execute "onExit" using a system shell
> -> Set the next state
> -> Reset counters
> -> Execute "do" using a system shell
> -> Execute "onEntry" using a system shell
>
> I'm still looking for a way to evaluate the guards: How can I execute these strings having all signals available?
>
> Another issue is IPC (inter process communication). The FSM is running in all time in its own process. If an event occurs (internet is available - for example) a seperate process (ppp's ip_up-script or whatever) must use ipc to trigger set_signal.
> What's the best way for ipc in your opionion? In theory (posix)-message queues should to the job, since queuing all events in the order they appear seem to be a logical, but their interface is rather complicated.

FSMs are something that have a lot of personal style choices, and Lua
is pretty flexible so any of them will work.

First, I would define the guards as functions, not strings. Then at
least you get to get syntax checking on them before runtime. So you
will want to name all the states (eg counters) so you can refer to
them in these.

Personally I like to define everything in an fsm as a function, so
each state is a function. Because Lua has proper tail recursion you
can just call the next state (in Javascript you have to use a
trampoline). Labels are fine too, but I find you can reuse state logic
by using parameterized functions and other things like that. Also I
like functions...

Posix message queues are not that bad to use. You could just use a
socket or pipe on the file system and send messages instead. You will
need to worry about blocking if there are a lot of messages, but in
most cases its probably not a problem.

Personally I think the idea of trying to coordinate what is going on
with a bunch of shell scripts is pretty nasty. I am working on a
native Lua (only LuaJIT right now) interface to all the low level
system stuff you need, like bringing up interfaces. Its not finished
by any means, there is a lot of work involved, but it is much more
direct talking to the kernel than forking a shell that talks to the
kernel then send a message back... See
https://github.com/justincormack/ljsyscall

Justin