Analytics Tracking Code

Saturday, June 22, 2013

Sun Blade 100 and OpenBSD

I find that I get distracted from the task at hand very easily.

My latest distraction from the FreeSWITCH on OpenBSD project has been a renewed interest in UltraSPARC hardware. I recently purchased a pair of Sun Fire V215 servers to act as routers, and on the way I got interested in the newer generations of UltraSPARC processors, which I think are very interesting for a variety of workloads that I have to deal with.

Anyway, this evening while out at my parents place I rummaged in the basement for a few minutes trying to find an old system I had left out here a few years ago.

Sure enough, sitting under a small pile of dust, I discovered my old Sun Blade 100 workstation. I had purchased the machine some years ago when I was working on a project which I wanted to ensure ran on big-endian architectures.

Plugging in the system, I was pleased to discover everything was exactly as I had left it (apparently in 2007 since it still had a OpenBSD 4.1 install disk inside it).

Quickly burning a copy of OpenBSD 5.3 for UltraSPARC, and running the install took about 10 minutes and I was pleased to discover a fully operational desktop.

OpenBSD 5.3 running out of the box on a Sun Blade 100 UltraSPARC workstation
These workstations were very useful in their day, and I am pleased to see that mine is still running.  Performance is a little lower than I would like for some activities like browsing the web, but its actually perfectly acceptable as a development environment (and nicely free of distractions too).

Sunday, June 2, 2013

FreeSWITCH on OpenBSD - Project Status 2013-06-02

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.

Recent Work

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".

Current tasks

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!