Proposal: "debug" branch for the kernel

[Carsten Haitzler (The Rasterman)]

On Wed, 9 Jul 2008 13:14:37 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

> Andy Green wrote:
> > Carsten's main goal seems as simple as "suspend if you can" and "you
> > can't suspend now", something trivial in kernel and perfectly handling
> > crashed apps, etc.
> 
> Yeah, Rome wasn't built in a day :-) What I think is important is
> to get this started. Once we have the basic infrastructure in place,
> even if it's just a skeleton, it will be easy to make it do more.
> 
> That's the difference to "oh, let's hack this into kernel, because
> writing something in user space would take a day of work".

aye. and that skeleton is. it's in svn:

svn co http://svn.openmoko.org/developers/raster/ompower

it's a skeleton with just enough meat to "do something useful" which is the
minimum requirement for actually having people use it! :) indeed this isnt
the end of it, but its a small yet very useful beginning - rome can be built
over time. the dbbus api modified and added to. i am not averse to alternate
communications mechanisms (eg just raw unix sockets so if u dont want to do
dbus complexity from your app you can use sockets instead)... but all in good
time. i would expect once screen blanking, backlight and cpu suspend/resume are
in good shape i will be adding power controls for other things (gps for
starters. splinter currently has some ugly hacks for turning gps on just for
itself then off again. being able to have it off by default until a client
brings it "online" and it stays online for all gps clients... until no one
indicates they want it anymore... we have wifi... bluetooth... etc. etc.

> > | That's why I'm so happy about finally getting that user space daemon.
> >
> > Oh?  You plan to write that daemon or even talk to it?  Cool.
>
> Well, it seems that Carsten is writing it, and it also seems that
> he and I agree on the basic principles. You can't imagine what
> satisfaction I draw from watching people doing what I think is
> right, without me having to do it myself ;-)

glad to be of serivce master! :) i agree that along the way we will disagree on
details and on how to do things and policies etc. and we will sort it out.
it's and incredibly small bit of code, so i haven't tried to over-engineer it
(yet) and thus it is very very very malleable to pretty much do whatever we
need. i wouldn't be surprised that we literally have a whole new policy module
per device we do (ompower will need to somehow be able to load such policy
modules, or we just literally have a #ifdef and build it per platform), but
we'll cross that bridge when we get to it. for now gta01, gta02 and even gta03
could be served by the one ompower codebase easily without #ifdef's or complex
module loading. i suspect into the future this can continue for a while... and
then maybe FSO will have its world sorted out and be ready to go? maybe FSO
will end up changing and adopting the ompower dbus api? i'm not fussed. i just
want our phones to work and work well. :)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>