Re: Full state machine implementation

Hi Neels, On Mon, Jul 11, 2016 at 03:15:00PM +0200, Neels Hofmeyr wrote: My comment above was not about the FSM, but about the OM2000 work, which is quite special-interest. Well, it's not going to be the grand unified theory that solves everything. It's an attempt at putting some more structure into some of the problems we need to solve, but I'm not sure if the first incarnation is already doing a good job at it. Implementing libvlr and OM2000 is sort of a test-ballon for it. While I like the "structured-ness" and the features about automatic clean-up of child FSMs, reporting of termination to the parent, ... there are also some parts that definitely leave much room for improvement. There's a lot of boilerplate code. I don't really like code generation that much, but maybe some macros could already help with that. Possibly, but the question is also one about 'how verbose / expressive is the code you need to do it' (I think too verbose / too little expressive yet with current osmo_fsm), and how easy is it to read. Finally, when handing in opaque structures as part of events, it all goes via 'void *' type casts. So a new class of problems could be introduced by this, one that we currently don't really have (except for osmocom-style signals) -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)