I felt it's time to recap the stuff that kept me busy the last months and give you an overview over the achievements planned for this year -- always focusing the free software movement, of course.
Let's start with the major project I've been working on, the freesmartphone.org project, funded by Openmoko, Inc. FSO grows, and it grows in the right directions. We get more API customers -- notably the SHR project and the Paroli project -- and refine our API and the reference implementation. The 5th milestone has just been released and apart from a major foobar with read-only partitions, it's pretty good. We are going to fix this OE-inheritance and release a milestone 5.1 in a couple of days.
For some modems -- e.g. the TI Calypso (see my previous post on ogsmd and its modems) -- until now we have relied on pyneo's gsm0710muxd. Over the last weeks we found some severe problems (race conditions, buffer overflows) with this though, so I thought I have a shot at developing my own GSM 07.10 Multiplexer.
The result is called fso-abyss and is -- as with all our software -- available at git.freesmartphone.org under a free software license. The major difference to gsm0710muxd is the architecture (and maintainability). While gsm0710muxd combines talking to the serial ports, the pty's, handling dbus queries, and doing modem specific things, fso-abyss went a different route.
At the heart there is a minimal protocol engine implementing GSM 07.10. Since there was already something available in Qtopia -- even nicely seperated without any external dependencies -- I took that one and factored it out in a dedicated project called libgsm0710 (available in git as well). The idea here is that different interest groups can collaborate on getting the protocol engine right, since not everyone wants a DBus frontend such as implemented in fso-abyss. The next step was writing a VAPI file for glueing the protocol engine to Vala (more about that one in a bit), which has been used to develop the upper layers of fso-abyss.
Last but not least, there was the pty implementation, the serial port communications abstraction, and finally the dbus server. The DBus API originally designed in cooperation with pyneo has been enhanced to feature the additional features (only) present in fso-abyss. Apart from the architecture, fso-abyss also can handle virtual serial port signalling, 07.10 test commands, automatic session handling, has a wakeup service, and more. Next up is adding support for the Cinterion mc75i which has some proprietary extensions to GSM 07.10 Basic Multiplexing.
Modern DBus APIs are pretty dynamic, i.e. objects can come and go at any time. Depending on the hardware, you may find more or less objects of a certain kind. You can now add infrastructure to query the objects (essentially a duplication of what DBus should provide), or just rely on the existing DBus introspection API. Unfortunately this API is missing some critical features to make it really usable, such as querying objects that implement a certain interface.
So I took the plunge and factored this out of the freesmartphone.org frameworkd, since it has broader use. This is the API for it (as introspected by mdbus):
root@om-gta02:~# mdbus -s org.freesmartphone.DBus /org/freesmartphone/DBus [METHOD] org.freesmartphone.DBus.ListBusNames() -> ( as:result ) [METHOD] org.freesmartphone.DBus.ListObjectPaths( s:busname ) -> ( ao:result ) [METHOD] org.freesmartphone.DBus.ListObjectsByInterface( s:busname, s:iface ) -> ( ao:result )
Here are examples of how you can use it (demonstrated within a Python shell):
>>> hlid.ListBusNames() [ 'org.freedesktop.DBus', 'org.freesmartphone.omuxerd', ':1.21', 'org.bluez', 'org.tichy.launcher', ':1.13', ':1.0', 'org.freesmartphone.frameworkd', ':1.14', ':1.1', ':1.2', ':1.3', ':1.4', 'org.freesmartphone.ogsmd', ':1.6', 'org.freesmartphone.DBus']
>>> hlid.ListObjectPaths("org.freesmartphone.ogsmd") ['/org/freesmartphone/GSM/Device', '/org/freesmartphone/GSM/Server']
>>> hlid.ListObjectPaths("org.freesmartphone.odeviced") [ '/org/freesmartphone/Device/Audio', '/org/freesmartphone/Device/CPU', '/org/freesmartphone/Device/Display', '/org/freesmartphone/Device/Display/0', '/org/freesmartphone/Device/Display/gta02_bl', '/org/freesmartphone/Device/IdleNotifier/0', '/org/freesmartphone/Device/Info', '/org/freesmartphone/Device/Input', '/org/freesmartphone/Device/LED/gta02_aux_red', '/org/freesmartphone/Device/LED/gta02_power_blue', '/org/freesmartphone/Device/LED/gta02_power_orange', '/org/freesmartphone/Device/LED/neo1973_vibrator', '/org/freesmartphone/Device/PowerControl/Bluetooth', '/org/freesmartphone/Device/PowerControl/UsbHost', '/org/freesmartphone/Device/PowerControl/WiFi', '/org/freesmartphone/Device/PowerSupply/ac', '/org/freesmartphone/Device/PowerSupply/adapter', '/org/freesmartphone/Device/PowerSupply/apm', '/org/freesmartphone/Device/PowerSupply/battery', '/org/freesmartphone/Device/PowerSupply/usb', '/org/freesmartphone/Device/RealTimeClock/0', '/org/freesmartphone/Device/RealTimeClock/rtc0']
>>> hlid.ListObjectsByInterface("org.freesmartphone.odeviced", "org.freesmartphone.Device.LED") [ '/org/freesmartphone/Device/LED/gta02_aux_red', '/org/freesmartphone/Device/LED/gta02_power_blue', '/org/freesmartphone/Device/LED/gta02_power_orange', '/org/freesmartphone/Device/LED/neo1973_vibrator']
While working on implementing GSM time(zone) support for ogsmd, we found we had too few samples, especially since time(zone) information are only sent by few providers all over the world. Moreoever, we missed a generic means to record all the data the frameworkd is sending out via its signals, such as:
To support this (and more), we came up with fso-monitord, which is available from git as well. fso-monitord logs its data to a flat file format that you can send to us to improve our databases or for debugging. We also figured this would be the best place to add a generic frameworkd watchdog -- monitoring all fso components -- shutting down or restarting components as necessary and also logging incidents such as API violations.
For milestone 5.5 (due end of march), we have two major features on the roadmap, namely bluetooth networking (headset profile) and extended PIM support. Milestone 6 will then sport full-fledged networking.
Beyond milestone 6 -- apart from one major thing, which I'll cover in a second -- we only have some rough plans, such as revamping or refining the subsystems we're not perfectly happy with (oeventsd and opreferencesd come to mind). Also, alsa audio scenario handling is broken by design, but this is something we have to take up with upstream.
The freesmartphone.org reference implementation has been progressing incredibly fast. This is partly due to choosing Python as the implementation language (which has been a wise choice) of our DBus APIs. Now you all know that although I truely love Python (I even wrote a book about it) and try to use it everywhere it fits, I'm very well aware that for the future of the freesmartphone.org project, it might be important to come up with a frameworkd reimplementation in a compiled language -- to reduce the footprint and squeak every possible bit of performance out of the (embedded) system.
This is why I have decided to encourage a second reference implementation. This one will be written in Vala (I might have mentioned it before, did I?) which is an incredible combination of elegance and performance, featuring a complete lack of any runtime penalties and additional dependencies. It's simply amazing and I'm seriously thinking about writing an introductionary book about Vala later this year.
Anyways, back to the topic, the first bits of this Vala implementation has landed in the freesmartphone.org git in the form of the very successful GSoC project odeviced, written by Sudarshan S. Stay tuned for some amazing FSO runtime speedups coming in autumn and winter this year to your device.
Next to writing software for the freesmartphone.org project, I also found some time to pick up working with my favourite writing tool LyX. LyX, which could be described as a LaTeX frontend, nowadays features integration with the new LaTeX variant XeTex. In contrast to other incarnations such as pdfLaTeX, XeTeX can utilize system fonts such as AAT or OpenType, which are the latest technology in computer-assisted typesetting.
I can now use my "corporate" fonts FF Meta and FF Meta Serif from LyX -- amazing!
Although still working on cutting down my travelling, I can't miss some conferences this year. I managed to skip FOSDEM, which made me a bit sad, but I'll be compensated by attending
and possible some more... This year my main topics will be OpenEmbedded and freesmartphone.org -- both dedicated to reducing the fragmentation of Linux-based embedded systems and to ease writing software for mobile devices running free and open source software. I hope we'll bump into each other at one of these occasions.
Stay tuned!