Hi Harald, I am reading the code on a daily basis, so no change is unnoticed :-) I am also reading your blog and watched most of your presentations on CCC. But back on the topic. I went through the code and for the first time I thought that the OM2000 code is somewhat generic and can be reused of the Nokia part. Then I realised that only the high level of the OML is standardised, the information elements for example do not, and the stuff in OM2000 files are specific to the RBS2000. Anyway, will take a closer look an try to figure out how this can be implemented for the Nokia part. Maybe this one will be a bit more interesting: there is a chance I can put my hands on a DBS3900 with a 2G baseband card in it :-) I am not sure how similar Huawei's IP Abis implementation is to what we have now, but I can certainly take a look :-) There's also some outstanding commits for Nokia regarding hopping, will try to rebase them for the current state of the BSC code and send it to you. Regards, Csaba ----- Eredeti üzenet ----- Feladó: "Harald Welte" <laforge(a)gnumonks.org> Címzett: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu> Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org> Elküldött üzenetek: Vasárnap, 2016. Július 10. 21:55:30 Tárgy: Re: Full state machine implementation Hi Sipos, On Sun, Jul 10, 2016 at 06:43:51PM +0200, Sipos Csaba wrote: I'm happy at least somebody notices this work :) It's not complete yet (hence the WIP), and it currently only implements the initialization as set of hierarchical state machines. The FSMs terminate once initialization is done. This could and should probably be further extended to having the BSC-side per-MO FSMs running persistently and tracking the state of their counterparts in the BTS. I also committed the OM2000 MO initialization sequences messace sequence charts to osmo-gsm-manuals, in case you're curious to see how code corresponds the protocol messages. Of course, why not? I've never looked too deep at the Nokia OML dialect/flavor though. I think for most users the more important part would be the generic one for the TS 12.21 managed objects, which then helps for nanoBTS, OsmoBTS and BS-11. Sure, I think it would make a lot of sense, technically. I'm just not sure how many OpenBSC useres with Nokia BTS are out there. But that shouldn't keep you from doing it, if you feel an urge to do so :) -- - 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)

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)