This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Neels,
On Mon, Jul 11, 2016 at 03:15:00PM +0200, Neels Hofmeyr wrote:
> On Sun, Jul 10, 2016 at 09:55:30PM +0200, Harald Welte wrote:
> >
> > I'm happy at least somebody notices this work :)
>
> I've actually more than once yearned for the FSM,
My comment above was not about the FSM, but about the OM2000 work, which
is quite special-interest.
> basically every time I'm fiddling with a request-response schema,
> tweaking timeout callbacks or trying to guard against messages coming
> in at the wrong time...
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.
> To me it seems that the FSM would improve correctness, reliability and
> maintainability at pretty much every interface I'm dealing with so far :)
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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)