With a subtle delay of something like 11 months, I managed to visit the friendly guys from Kernel Concepts in Siegen last week. The most important subjects were how to move forward with regards to a phone server and device daemon collaboration. Here is a short summary what these two things are, why we need them, and what we are going to do.
PhoneServer
A phone server encapsulates the access to the telephony subsystem. It is necessary to allow multiple clients query the state of the subsystem and to perform operations taking non-functional requirements like concurrent access, security, information caching, and quality of service, etc. into account. Similar components can be found in lots of closed source smartphone platforms. The free software community is still missing such a component. Yes, there are first approaches in OpenMoko (libgsmd), Qtopia, GPE Phone Edition, and probably more, but neither one supports all our requirements on such a component.
I have been reluctant to think about a phone server until being more certain about its place in the platform and the way it should talk to both the upper layers and the lower layers. As reported in previous installments of this column, by now I am sufficiently convinced that dbus is the proper abstraction (and collaboration) line, hence the phone server needs to talk dbus.
We will now start to work on a minimal dbus interface specification of the phone server. Since the folks that brought us the GPE Phone Edition have good contacts to the Linux Phone Standards forum, we are expecting input from people who have tons of experience with telephony APIs. However, this will not just be a completely free and open specification process, but also backed up by code -- in the good tradition of FOSS projects. So, I'm inviting everyone and their brother to collaborate on this telephony API. Especially application programmers, please tell us which syntax and semantics you prefer. I have just opened the freesmartphone.org wiki and will fill it with some of our initial thoughts soon.
The first milestone will be a phone server that talks to libgsmd, although I'd love to see a backend for the Qtopia gsm code as well. I'm very happy to see Ixonos' work on gsmd2, I'm sure this also will be some valuable input for us -- perhaps even an alternative backend or more!
DeviceDaemon
The other thing everyone wants but seems reluctant to work on is a peripheral device daemon. Throughout my involvement in the embedded Linux community I have seen dozens of those daemons in different flavours, all more or less device specific, hardcoded, not extensible, etc. I myself have implemented more than one hardware abstraction layer from scratch. The desktop world has HAL, OpenMoko has neod, GPE Phone has machined, the Zaurus guys have zaurusd, Opie had odevice, and more! All that duplicated work should really end now and be consolidated into one extensible lightweight machine and peripheral daemon.
As with the phone server, over the next couple of days I will add some initial thoughts into the freesmartphone.org wiki. Please see Florian's blog post here and this wiki page for some more details. Right now it's not even clear whether we need something completely new -- we also consider stripping down HAL or reimplementing it using the same dbus interface to be able to reuse OHM.
Again, I'd be delighted if we can could quickly start adding some real world requirements and dive into coding. Please feel invited to contribute.