gsmd/libgsm suckage (was Re: gsmd/libgsm architecture)

[Harald Welte]

Hi Koen!

On Thu, Jul 19, 2007 at 11:58:31PM +0100, Koen Kooi wrote:

> My suggestion is to use dbus to interface with libgsmd instead of the
> fragile /var/tmp/uberleet.socket stuff. If it does that, the locking
> problems and races go away magicallyand multiple clients actually
> work.

well, the main issue is that openmoko (the project, the company, ...)
has tons of way more important (non-technical) low-level problems that I
need to look into.

This combined with the fact that due to the
organizational/administrative history, we don't really yet have any
internal software development team of significant size and/or skill yet.

In other words: A lack of time.

Whether you put the time into a dbus interface, or whether you put it
into actually finishing the current interface doesn't really make that
much difference.

I am very well aware that the current code is nothing but a unfinished
prototype to get something working at all.  Nobody has any doubt about
that. If you look at my work, particularly in the netfilter area, then
you will see that I actually don't have problems implementing
system-level daemons (ulogd, ulogd2, ipqmpd, and a couple of non-free
ones that you can unfortunately not look at) with socket interfaces,
given the right amount of time.
 
I personally literally hate to have dependencies on anything bug glibc
(and maybe libusb or similar things that are needed for low-level
access).  As indicated before, I don't mind having something like a dbus
interface, if it's a plugin that can optionally be built.

Getting back to the time problem:  Now my constant choice for the last
six months was:

1) work on technical stuff such as drivers, gsmd, etc and make the
   software more complete
2) work on hardware fixes (GTA01), partial design (GTA02) or actual
   real redesign (future roadmap) to make sure we actually have
   something that I would consider acceptable (GTA01 isn't to me, and
   GTA02 is just a hot-fix to it).
3) work on administrative/organizational issues, to make sure this
   project has a future at all, that it has the resources it needs,
   and that there is at least some planning at some point, rather than
   total anarchy where everyone just does what he thinks, with no
   visible result.
4) give gmsd/libgsmd to somebody else in the project, whom I think has
   both the technical skill as well as a similar taste when it comes
   to the architectural point of view

'1' is what I did whenever I could, and as you will probably agree,
having lowlevel kernel drivers is somewhat more important than the gsm
daemon.

'2' is what I choose to do most of the time during some periods of time,
and with which I still spend a lot of time.  I actually thing GTA01 is
an embarrassment, and we really need to get to a totally different level
of integration, flexibility, quality mechanical quality, ....

'3' is what I spend most of my time those days.  Unfortunately this item
is sort of a precondition for all other items.  Unless OpenMoko (the
company) as well as FIC Mobile Communications (the hardware business
unit in FIC) get the proper resources, structure, policies, vision,
plan, etc. there is no point talking about any technical issues at all.
Yes, I could have provided the most perfect gsmd implementation ever,
but then we probably would not have any future roadmap, and the project
woold cease to exist after 1000 GTA01 shipped.

'4' is an option that didn't really exist ontil now.  We have one person
in the team now whom I would trust both the technical skill, the
familiarity with the involved standards, and the taste in architecture
to really work on this.  However, even that person is completely
overloadd with other tasks and actually fell asleep in front of his
keyboard at some point probably 3am/4am at night, in the office last
week.

So yes, everything sucks.  Our current hardware sucks still quite a bit,
but works.  Our current bootloader/kernel works reasonably well.  Our
GSM infrastructure sucks big time, and if you look at the UI, then,
until recently it also sucked quite significantly.

But on average, I don't really think that gsmd sucks more than the
average level of openmoko suckage.  If there is no progress soon, it
will be below average.  I'll try to keep it at least on average level.
And with some hope, '4' is an option within the next four weeks.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone