I've finally gotten around to making new headway with the FreeSWITCH on OpenBSD project. Although I can honestly see at least year (or more, really) of labour in front of me to produce a high quality port which I would be content to run my voice services on.
At the moment, I have a semi functional build which compiles a binary capable of executing just past the banner. I haven't checked the last call trace yet, however it looks like we are breaking just after the process forks and spins up a bunch of threads.
I merged a commit today that replaces the hash table wrapper that used to point at internal sqlite APIs to a the public hash table implemented by APR. This is in reaction to an instant crash bug that I was encountering when the old system tried to access the internal sqlite malloc code.
I'll note that the original implementation of the hash table stuff used APR in the good old days (2008) and was replaced by Anthony for reasons that I am currently unclear about.
The results tested well in an impromptu set of test cases I whipped up to see if things should work, and the configurations loaded successfully, however the test of the new implementation really will only happen down the road when we start flinging calls around.
I find the code style of the FreeSWITCH developers difficult to read for a couple reasons:
- Long symbol that_describe_what_should_be_happening_like_this
- Long prototypes that disappear off the edge of my monitor, I've seen lines with more than 180 characters which is a bit much.
I'm not going to whinge about the code style too much since it is what it is, however I've voiced my official note saying I don't like it.
Another issue I have is with the munging of dependencies. What I mean here is that the developers have taken a number of liberties in changing the internals of some dependencies. I suppose that they had their reasons, however it does make me twitch.
The more I fiddle with the internals of FreeSWITCH, the more I approve of the projects that have come from the OpenBSD guys. Especially when it comes from the perspective of portability, where the dependency trees are vanishingly small. The FreeSWITCH perspective is somewhat along the lines of "ok, this pile of kitchen sinks seems balanced, don't fuck with it".
There are couple items to do right away. The first is spin up the module loading code, port some modules, and verify that the core modules are loading in what appears to be a correct manner.
Also I noticed that I am statically linking my internal libfreeswitch library and that needs to stop.
Down the road
I really dislike the manner in which freeswitch loads its configuration. On the horizon is a new launching and configuration loading change that makes me less twitchy. I'll make sure that everything I do here could be conceivably imported upstream.
Also, there are couple areas that I think may need special attention, memory handling and threading
There is lots left to do!